CM 

■H 

00 

9 

cr 


cr 

LU 

o 


o 

Q 

cr 

LU 


US  Army  Corps 
of  Engineers® 

Engineer  Research  and 
Development  Center 


IMCOM  Lon  Works®  Building  Automation 
Systems  Implementation  Strategy 

Final  Report 

David  M.  Schwenk,  Joseph  Bush,  Lucie  M.  Hughes,  September  2008 

Stephen  Briggs,  and  Will  White 


DUO 

■ 

<5 

c  o 

c5  2 

LU  O 
_Q 

O  _| 


O 


O 


+-»  CD 
CO  0 
C  CO 
O  0 

o  cr 


Bldg  1  Bldg  2  Bldg  3 


BPOC=Building  Point  of  Connection  (UMCS  to  Building  Control  Network) 


Approved  for  public  release;  distribution  is  unlimited. 


ERDC/CERL  TR-08-12 
September  2008 


IMCOM  LonWorks®  Building  Automation 
Systems  Implementation  Strategy 

Final  Report 


David  M.  Schwenk  and  Joseph  Bush 

Construction  Engineering  Research  Laboratory  (CERL) 

U.S.  Army  Engineer  Research  and  Development  Center 
2902  Newmark  Dr. 

Champaign,  IL  61824 

Lucie  Hughes 

U.S.  Army  Corps  of  Engineers  Savannah  District 

Will  White 

U.S.  Army  Corps  of  Engineers  Huntsville  Engineering  and  Support  Center 

Dr.  Stephen  Briggs 

Facility  Dynamics  Engineering 
Columbia,  MD 


Final  Report 


Approved  for  public  release;  distribution  is  unlimited. 


Prepared  for  Headquarters,  U.S.  Army  Corps  of  Engineers 
Washington,  DC  20314-1000 


ERDC/CERL  TR-08-12 


Abstract:  Army  Installations  often  expand  their  use  of  digital  control 
systems  for  heating,  ventilating,  and  air  conditioning  and  other 
mechanical  and  electrical  building  systems  on  a  building-by-building 
basis.  Associated  control  systems  are  installed  under  separate  contracts  by 
different  contractors  resulting  in  intra-system  incompatibilities.  The 
implementation  of  multi-vendor  Open  Building  Automation  Systems 
(BASs)  is  meant  to  overcome  such  incompatibilities;  however  BASs  can 
present  their  own  technical  and  administrative  (including  contractual) 
challenges.  This  report  defines  a  methodology  for  the  development  and 
execution  of  a  basewide  Open  Building  Automation  System  (BAS) 
implementation  plan  based  on  LonWorks  ®  technology  and  American 
National  Standards  Institute  (ANSI)  communications  standard  709.1 
where  the  BAS  consists  of  a  basewide  Utility  Monitoring  and  Control 
System  (UMCS)  that  is  interoperable  with  multi-vendor  LonWorks  ® 
direct  digital  control  (DDC)  systems. 
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ecutive  Director  of  ERDC  is  COL  Gary  Johnston,  and  the  Director  of  ERDC 
is  Dr.  James  R.  Houston. 
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1  Introduction 

1.1  Background 

Army  Installations  are  expanding  their  use  of  direct  digital  control  (DDC) 
systems  for  heating,  ventilating,  and  air-conditioning  (HVAC)  and  other 
mechanical  and  electrical  building  systems,  often  on  a  building-by- 
building  basis,  in  which  the  control  systems  are  installed  under  separate 
contracts  by  different  contractors  resulting  in  incompatibilities  between 
the  separate  systems.  Significantly,  these  systems  are  often  installed  with¬ 
out  the  planning,  preparation,  training,  and  ground  rules  needed  to  obtain 
a  functional,  usable,  expandable  and  (most  notably),  supportable  system. 

The  implementation  of  multi-vendor  Open  Building  Automation  Systems 
(BASs)  present  both  technical  and  administrative  (including  contractual) 
challenges.  A  Building  Automation  System  (BAS),  within  the  context  of 
this  document,  includes  one  or  more  building-level  DDC  systems  interop¬ 
erating  with  a  supervisory  Utility  Monitoring  and  Control  System  (UMCS) 
where  the  UMCS  is  used  to  monitor  and  manage  the  DDC  systems.  A  long¬ 
standing  goal  of  most  Army  installations  is  to  implement  a  basewide  BAS 
as  opposed  to  multiple  separate  and  independent  BASs.  A  successful  BAS 
is  one  that  is  functional,  energy  efficient,  and  cost  effective. 

More  importantly,  a  BAS  must  support  the  needs  of  the  building  occu¬ 
pants,  operations  and  maintenance  (O&M)  staff,  and  management.  Even 
though  industry  standards  and  specification  guidance  are  available,  there 
are  many  potential  pitfalls.  The  following  Unified  Facilities  Guide  Specifi¬ 
cations  (UFGSs)  for  BASs  based  on  LonWorks  ®  technology  and  American 
National  Standards  Institute  (ANSI)  standard  709.1  communications  pro¬ 
tocol  were  released  in  FY04: 

•  DDC  Guide  Specification.  Unified  Facilities  Guide  Specification 
(UFGS)  23  09  23  (previously  UFGS  15951):  Direct  Digital  Control  for 
HVAC  and  Other  Building  Systems. 

•  UMCS  Guide  Specification.  UFGS  25  10  10  (previously  UFGS  13801): 
Utility  Monitoring  and  Control  System  (UMCS) 

These  UFGSs  were  designed  to  address  many  open  system  pitfalls,  but  im¬ 
plementation  challenges  extend  beyond  the  designer’s  ordinary  realm  of 
responsibility. 
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UFGS  23  09  23  (the  DDC  guide  spec)  specifies  controls  at  the  building 
level  and  UFGS  25  10  10  (the  UMCS  guide  spec)  specifies  the  supervisory 
and  basewide  system.  These  criteria  were  developed  to  help  with  the  im¬ 
plementation  of  Open,  non-proprietary,  and  interoperable  multi-vendor 
DDC  systems  that  integrate  with  a  UMCS.  The  UMCS  is  intended  to  be  a 
single  system  that  serves  as  a  basewide  interface  to  the  multi-vendor 
building -level  DDC  systems.  The  intent  of  both  the  DDC  and  UMCS  guide 
specs  is  to  specify  and  procure  an  Open  system.  In  practice,  the  UMCS 
user  interface  software  will  be  procured  from  a  single  vendor,  although  the 
specification  is  written  to  ensure  the  overall  BAS  remains  Open.  Figure  1 
illustrates  a  UMCS/DDC  system  where  multiple  building  DDC  systems 
have  been  integrated  into  a  single  UMCS  that  provides  multiple  operator 
workstations  (“UMCS  Client”).  Figure  2  also  shows  the  UMCS/DDC  sys¬ 
tem  and  distinguishes  between  the  UMCS  and  DDC  elements  specified  by 
the  two  guide  specifications. 

An  Open  system,  in  short,  is  one  where  there  is  no  future  dependence  on 
the  original  installing  Contractor.  For  the  purposes  of  procurement,  this 
means  that  there  is  no  sole  source  dependence  on  any  Contractor  for  fu¬ 
ture  system  additions,  upgrades,  or  modifications.  An  Open  system  helps 
to  avoid  proprietary  sole  source  procurement  in  accordance  with  Govern¬ 
ment  procurement  rules.  In  practice,  single-source  procurement  of  the  in¬ 
tegration  of  building-level  DDC  systems  into  the  UMCS  is  valuable,  but 
single-source  procurement  can  and  should  be  avoided  for  the  building- 
level  DDC  systems.  Methods  for  procuring  and  expanding  the  UMCS  are 
discussed  in  Section  2.4  ,  “Identify  building  integration  approach”  (p  23). 
Related  BAS  implementation  guidance  and  information  is  available  in  En¬ 
gineering  and  Construction  Bulletin  (ECB)  2004-11,  ECB  2005-17,  ECB 
2007-8,  and  ERDC/CERL  Technical  Reports  TR-05-14  and  TR-07-03. 
Additional  information  along  with  updates  to  the  material  contained  in 
this  report  may  be  found  at:  https://eko.usace.army.mil/fa/bas/ 

1.2  Objective 

The  objective  of  this  work  was  to  define  and  document  a  methodology  that 
will  serve  as  a  tool  for  the  development  and  execution  of  a  basewide  Open 
BAS  implementation  plan  based  on  LonWorks®  technology  and  ANSI 
communications  standard  709.1,  where  the  BAS  consists  of  a  basewide 
UMCS  that  is  interoperable  with  multi-vendor  LonWorks®  DDC  systems. 
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Bldg  1  Bldg  2  Bldg  3 


BPOC=Building  Point  of  Connection  (UMCS  to  Building  Control  Network) 

Figure  1.  Basewide  LonWorks®  BAS— including  a  UMCS  and  multiple-vendor  DDC  systems. 


Figure  2.  BAS  comprised  of  UMCS  and  DDC  systems. 
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1.3  Approach 

The  initial  step  of  this  project  involved  the  creation  and  execution  of  an 
implementation  plan  for  LonWorks®  building  automation  systems,  docu¬ 
mented  in  this  report.  In  coordination  with  Huntsville  Mandatory  Center 
of  Expertise  for  UMCS  and  Savannah  District  Directory  of  Expertise  for 
HVAC  Control  Systems,  the  strategy  described  in  ERDC-CERL  TR-07-16 
was  implemented  over  the  course  of  FY07  at  five  Army  installations:  Fort 
Bliss,  Fort  Bragg,  Fort  Hood,  Fort  Lee,  and  Fort  Sill.  The  lessons  learned 
from  field  implementation  at  these  installations  have  been  incorporated 
into  this  report,  which  provides  guidance  on  the  development  and  execu¬ 
tion  of  an  implementation  plan.  The  appendices  to  this  report  contain  a 
variety  of  sample  documents  and  templates  (discussed  in  Chapter  2)  pre¬ 
pared  to  aid  installation  planners  in  developing  their  planning,  contract¬ 
ing,  and  execution  documents: 

•  Appendix  A:  Control  Systems  Assessment  Statement  of  Work  (p  39) 

•  Appendix  B:  DOIM  FAQ  (p  47) 

•  Appendix  C:  DOIM  MOU  (p  52) 

•  Appendix  D:  Installation  Design  Guide  Draft  Verbiage  (p  54) 

•  Appendix  E:  UMCS  System  Administrator,  Tech  Support  Rep,  and  Sys¬ 
tem  Integrator  SOW  (p  58) 

•  Appendix  F:  UMCS  DDC  Integration  SOW  (p  70) 

•  Appendix  G:  DDC  Integration  Process  via  MIPR  (p  75) 

•  Appendix  H:  Example  Implementation  Plan  (p  78). 

•  Appendix  I:  LonWorks  Compliance  Assessment  Tool  (p  91). 

1.4  Scope 

This  document  provides  guidance  on  the  creation  of  an  installation- 
specific  building  automation  system  implementation  plan  with  an  empha¬ 
sis  on  the  definition,  specification,  and  procurement  of  an  Open  basewide 
UMCS.  Limited  guidance  on  the  implementation  of  building-level  DDC 
systems  is  included.  Specifically,  building-level  DDC  guidance  focuses  on 
those  requirements  that  deal  with  system  interoperability  with  the  UMCS, 
overall  system  functionality,  and  maintainability.  While  this  methodology 
is  Army-specific,  it  may  be  generically  suitable  for  use  by  other  military 
and  nonmilitary  users.  Similarly,  while  this  methodology  is  specific  to  the 
implementation  of  LonWorks  based  on  the  UFGSs,  portions  of  it  may  be 
generically  suitable  for  a  BAS  using  a  different  technology  or  protocol. 


ERDC/CERL  TR-08-12 


5 


1.5  Mode  of  technology  transfer 

This  report  will  be  made  accessible  through  the  World  Wide  Web  (WWW) 
at  URL:  http://www.cecer.army.mil 
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2  BAS  Implementation 

Development  and  execution  of  a  BAS  Implementation  Plan  is  the  respon¬ 
sibility  of  the  Installation.  This  development  and  execution  can  be  accom¬ 
plished  using  combination  of  internal  and  external  resources,  where  ex¬ 
ternal  resources  may  be  necessary  to  obtain  technical  assistance  and 
UMCS  procurement  assistance.  The  following  sequence  of  tasks  and 
events  describe  the  development  of  an  integration  plan  and  subsequent 
procurement  of  a  basewide  UMCS: 

1.  Assemble  a  BAS  workgroup  (Section  2.1 ,  following  section) 

2.  Identify  issues,  goals,  and  obstacles  (Section  2.2 ,  p  10) 

3.  Identify  approach  to  address  obstacles  (Section  2.3  ,  p  13) 

4.  Develop  statement(s)  of  work  (SOW[s])  to  obtain  external  technical  assis¬ 
tance  (Section  2.3.1 ,  p  14) 

5.  Coordinate  with  Directorate  of  Information  Management  (DOIM)  (Section 

2.3.2 ,  p  14) 

6.  Define/develop  building  acceptance  methodology  and  checklists  (Section 

2.3.3 ,  P  21) 

7.  Define  training  requirements  (Section  2.3.4  >  P  22) 

8.  Develop  Installation  Design  Guide  (IDG)  requirements  and  in-house 
LonWorks®  specs  (Section  2.3.5  >  P  23) 

9.  Identify  building  integration  approach  (Section  2.4 ,  p  23) 

10.  Develop  UMCS  System  Administrator,  Technical  Support  Representative, 
and  System  Integrator  SOW  (Section  2.4.5  >  P  30) 

11.  Document  implementation  plan  (Section  2.5 ,  p  31) 

12.  Execute  UMCS  procurement  (Section  2.6  ,  p  33). 

This  sequence  is  not  fixed.  The  individual  tasks/events  along  with  the  or¬ 
der  might  vary  depending  on  the  installation’s  situation  and  needs. 

2.1  Assemble  a  BAS  workgroup 

The  Workgroup  should  minimally  consist  of: 

•  Energy  Manager 

•  Chief  of  Directorate  of  Public  Works  (DPW)  O&M 

•  DPW  Shop  and/or  work  leader 
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•  DPW  mechanic(s) 

•  Plans  and  Programs  (P&P) 

•  DOIM  and  the  Corps  Area  and/or  Resident  Engineer. 

The  Workgroup  may  also  include  the  Corps  District  designer  and  external 
consultants  such  as  Huntsville  Center  (HNC),  Savannah  District  (SAS)  and 
the  Engineer  Research  Development  Center  Construction  Engineering  Re¬ 
search  Laboratory  (ERDC-CERL). 

Not  all  members  of  the  Workgroup  need  to  be  involved  in  the  entire  im¬ 
plementation  plan  development  and  execution  process,  but  all  members 
can  be  expected  to  contribute  at  various  stages  of  plan  development,  and 
all  members  will  benefit  from  the  final  plan.  A  statement  of  intent  should 
be  communicated  to  the  Chief  of  DPW  and  the  Garrison  Commander 
through  a  memo,  e-mail,  or  meeting  since  support  of  these  individuals  will 
be  valuable  to  the  successful  development  and  implementation  of  the  plan. 

Generally,  workgroup  roles  and  responsibilities  will  be: 

•  Energy  Manager.  As  the  lead  person  responsible  for  energy  conserva¬ 
tion  and  ultimately  responsible  for  operating  and  maintaining  the  BAS, 
at  the  installation,  the  Energy  Manager  will  be  primarily  responsible 
for  ensuring  that  the  BAS  functionality  achieves  the  desired  level  of  en¬ 
ergy  performance.  This  will  require  review  of  sequences  of  operation  in 
the  buildings,  review  of  any  installation-wide  demand-limiting  func¬ 
tionality,  determination  of  metering  requirements,  and  requests  for  in¬ 
stallation  of  new  hardware  for  energy  efficiency.  The  Energy  Manager 
should  also  ensure  that  any  needed  software  or  hardware  tools  re¬ 
quired  to  perform  O&M  (e.g.,  laptops  equipped  with  configuration 
software)  is  included  with  the  procurement. 

•  Chief  of  DPW  O&M.  The  Chief  of  O&M  must  ensure  that  the  BAS  can 
be  supported  by  the  DPW.  This  will  require  review  of  proposed  se¬ 
quences,  control  hardware,  and  front  end  functionality.  Particular  at¬ 
tention  will  be  needed  to  ensure  that  the  front-end  user  interface  pro¬ 
vides  easy-to-use  access  to  features  the  O&M  staff  deems  essential. 
Finally,  the  Chief  is  responsible  for  ensuring  that  necessary  training  is 
provided  and  that  O&M  staff  are  available  to  participate  in  the  training. 
DPW  buy-in  and  ownership  of  the  BAS  is  essential  for  a  successful  pro¬ 
ject. 
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•  DPW  Shop  Leader  and  Mechanics.  The  advice  and  expertise  of  the  in¬ 
dividuals  who  will  operate  and  maintain  HVAC  equipment  operated  by 
the  BAS  is  critical.  The  maintenance  staff  ordinarily  has  a  wealth  of 
hands-on  experience.  They  likely  can  also  provide  valuable  input  for 
defining  training  needs. 

•  Plans  and  Programs.  In-house  designs  must  be  accomplished  in  ac¬ 
cordance  with  the  BAS  Implementation  Plan  (described  later)  and  re¬ 
sultant  BAS  requirements. 

•  DOIM.  As  the  organization  responsible  for  the  basewide  Information 
Technology  Local  Area  Network  (IT  LAN),  and  in  particular  responsi¬ 
ble  for  security  on  this  LAN,  the  DOIM’s  role  in  supporting  the  BAS  in¬ 
stallation  and  in  ensuring  that  the  BAS  meets  Army  requirements  can¬ 
not  be  overstated.  Their  participation  in  the  working  group  is 
absolutely  essential  for  a  successful  BAS  installation.  Modern  BASs  re¬ 
quire  a  basewide  Internet  Protocol  (IP)  network  for  operation  (the 
basewide  IT  LAN  is  an  IP  network).  Coordination  with  the  DOIM  in 
obtaining  this  IP  network  is  essential.  While  modern  BASs  have  many 
similarities  to  IT  systems,  which  may  raise  red  flags  with  the  DOIM, 
there  are  also  important  differences  that  can  mitigate  their  concerns;  a 
well-informed  DOIM  is  the  best  insurance  against  major  roadblocks 
later  in  the  installation  process.  For  example,  while  the  BAS  as  speci¬ 
fied  in  UFGS  23  09  23  and  UFGS  25  10  10  does  not  rely  on  HTML,  Ex¬ 
tensible  Markup  Language  (XML),  Web  Services,  or  http,  for  commu¬ 
nication  between  the  front  end  and  building  controls  (and  in  fact 
requires  use  of  a  different  mechanism)  some  BAS  vendors  may  include 
products  using  these  protocols  in  their  submittals,  and  thus  coordina¬ 
tion  with  the  DOIM  is  needed  to  ensure  that  these  products  meet 
DOIM  requirements  or  are  rejected. 

•  Corps  Area  and/or  Resident  Engineer.  The  Corps  Area  and/or  Resi¬ 
dent  Engineer  is  the  party  primarily  responsible  for  system  installation 
and  commissioning,  and  for  ensuring  that  the  BAS  meets  the  contract 
requirements  and  performs  as  specified.  It  is  an  unavoidable  fact  that 
Open  System  procurement  and  installation  is  more  challenging  than 
that  of  proprietary  systems.  Much  of  UFGS  23  09  23  and  UFGS  25  10 
10  is  dedicated  to  communication  issues/requirements;  functionality 
that  would  just  be  “assumed  to  work”  in  a  proprietary  procurement.  In 
addition,  while  UFGS  23  09  23  and  UFGS  25  10  10  provide  guide  speci¬ 
fications,  it  is  anticipated  that  designers  will  modify  the  specifications 
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due  to  project-specific  requirements.  For  these  reasons,  it  is  important 
that  the  Area  and/or  Resident  Engineer  be  involved  in  this  process. 

•  External  Consultants.  Most  Corps  design  offices  are  overworked,  and 
as  previously  noted,  Open  System  procurement  will  be  more  challeng¬ 
ing  than  proprietary  procurement.  For  this  reason,  and  particularly  in 
the  initial  phases,  it  can  be  beneficial  to  obtain  outside  expert  assis¬ 
tance,  such  as  can  be  obtained  from  the  Huntsville  Mandatory  Center 
of  Expertise  (MCX)  for  UMCS,  Savannah  Directory  of  Expertise  (DX) 
for  HVAC  Control,  or  the  Engineer  Research  Development  Center 
(ERDC).  Other  private  consultants  may  be  equally  valuable.  However 
at  this  time,  few  may  have  an  in-depth  familiarity  with  the  guide  speci¬ 
fications. 

Finally,  although  not  explicitly  members  of  the  Workgroup,  the  success  of 

the  BAS  installation  depends  on  several  other  individuals/organizations: 

•  Chief  of  DPW.  The  Chief  of  DPW  can  assist  the  Workgroup  with  advo¬ 
cacy  across  all  DPW  offices  and  well  as  between  the  DPW  and  DOIM, 
Job  Order  Contracts,  P&P  etc. 

•  Garrison  Commander.  A  Garrison  Commander  who  recognizes  the 
value  of  a  BAS  that  meets  specifications  can  be  a  powerful  advocate  for 
getting  a  functioning  BAS;  the  Garrison  Commander’s  buy-in  is  critical. 

•  Contracting  Officer.  BAS  Contracts  can  be  challenging  due  to  complex 
requirements  and  potentially  burdensome  contracting  procedures  such 
as  the  establishment  of  an  indefinite  delivery  indefinite  quantity 
(ID/IQ)  contract  for  system  integration/support  services.  The  Work¬ 
group  should  (and  may  already)  recognize  this  challenge. 

•  Building  Tenants.  Occupants  are  often  (understandably  so)  in  a  great 
hurry  to  move  into  a  new/renovated  building  and  often  force  beneficial 
occupancy  before  the  BAS  is  complete.  Occupants  who  understand  the 
need  for  the  BAS  to  function  according  to  specification  and  can  delay 
their  move  until  the  BAS  is  fully  commissioned  can  become  powerful 
champions  of  a  successful  BAS  procurement.  This  frequently  requires 
education  of  the  tenants,  whom  seldom  understand  the  impact  of  a 
dysfunctional  BAS. 

•  Corps  District  Designer.  Designs  must  be  accomplished  in  accordance 
with  the  installation’s  BAS  Implementation  Plan  and  requirements 
while  working  within  the  framework  of  UFGS  23  09  23  and  UFGS  25 
10  10.  Membership  in  the  Workgroup  is  optional,  but  communication 
and  coordination  with  the  Corps  District  is  essential. 
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2.2  Identify  issues,  goals,  and  obstacles 

The  Workgroup  must  address  the  current  status  of  the  installation’s 
BAS(s).  This  includes  creating  lists  of  issues,  goals  and  obstacles.  These 
lists  do  not  need  to  be  rigorously  detailed,  but  should  be  as  complete  as 
possible  since  they  will  be  an  important  part  of  the  final  implementation 
plan  for  the  BAS.  Also,  they  are  important  to  help  identify  any  “broken” 
policies  or  procedures  that  need  to  be  addressed.  Of  equal  importance  is 
for  the  group  to  recognize  (and  not  waste  time  on)  problems  that  the  BAS 
will  not  solve;  the  BAS  is  not  a  panacea  and  will  not  solve  systemic  pro¬ 
curement,  commissioning,  financial,  or  O&M  issues. 

2.2.1  Identify  issues 

The  first  part  of  this  step  is  to  identify  the  main  issues  that  exist  with  the 
current  system  or  that  the  Workgroup  feels  might  exist  with  future  sys¬ 
tems.  This  list  of  issues  will  be  used  to  help  identify  the  goals  of  the  new 
BAS.  Some  issues  commonly  experienced  by  installations  are: 

•  Multiple  BASs  exist.  In  some  cases,  installations  have  made  the  deci¬ 
sion  to  maintain  multiple  independent  BASs  as  a  means  to  allow  com¬ 
petitive  procurement.  In  other  cases,  multiple  BASs  are  a  result  of  the 
procurement  of  incompatible  systems.  In  either  situation,  it  is  gener¬ 
ally  more  costly  to  maintain  and  expand  multiple  systems  than  a  single 
system.  Multiple  BASs  generally  lead  to  the  following  specific  prob¬ 
lems: 

o  Many  O&M  laptops  that  are  not  used.  This  often  occurs  when  sys¬ 
tems  from  many  manufacturers  are  installed  and  these  software 
tools  are  provided  with  limited  training.  Without  training  in,  and 
frequent  use  of  these  tools,  skills  deteriorate  and  the  installation’s 
ability  to  troubleshoot  and  manage  its  systems  is  hampered, 
o  Too  many  front-end  software  packages.  There  may  be  too  many 
front-end  computers  when  multiple  BASs  exist.  Each  system  re¬ 
quires  its  own  front-end  interface  and  it  takes  several  interfaces 
(software  packages)  to  monitor  the  entire  network.  An  installation 
may  find  it  difficult  to  maintain  training  and  skills  on  multiple 
front-ends,  which  often  hampers  its  ability  to  effectively  use  the 
BAS  systems. 

•  Not  enough  fi'ont- end  computers  At  the  other  extreme,  the  installation 
may  have  no  front-end  computer  or  other  operator  interface  at  all. 
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These  systems  are  extremely  difficult  to  use  and  maintain  since  it  is  dif¬ 
ficult  to  determine  what  they  are  doing. 

•  Insufficient  training.  The  O&M  staff  is  not  adequately  trained  on  the 
use  and  operation  of  the  system. 

•  Insufficient  or  superfluous  BAS  features.  The  BAS  includes  features 
that  are  not  needed  and  possibly  confuse  operators,  or  the  BAS  does 
not  include  features  that  are  needed/desired  by  the  installation  (such 
as  demand  limiting). 

•  Systems  never  worked.  Systems  are  accepted  even  though  they  are  not 
functioning  properly.  This  is  a  result  of  poor  commissioning  of  the  sys¬ 
tems,  which  in  turn  can  be  due  to: 

o  Lack  of  time  at  the  end  of  the  project  to  adequately  commission  the 
systems  (often  due  to  delays  earlier  in  the  project  and/or  tenant- 
imposed  deadlines  for  completion) 
o  Specification  of  overly-complex  systems  i.e.,  systems  beyond  the 
technical  expertise  of  the  commissioning  agents  to  adequately 
evaluate. 

•  DPW  not  involved.  The  DPW  is  not  involved  in  the  acceptance  process 
for  BASs  so  there  is  no  sense  of  ownership  by  those  that  will  have  to 
maintain  the  system. 

•  BASs  are  underused.  This  usually  occurs  because  the  BASs  are  not 
properly  configured  to  provide  useful  feedback  to  the  operators,  or  is 
due  to  inadequate  training.  As  a  result,  systems  are  generally  operated 
in  a  “full  manual”  mode,  with  systems  running  24/7  under  fixed  oper¬ 
ating  conditions.  While  systems  operated  in  this  manner  may  be  con¬ 
figured  to  satisfy  occupant  comfort  or  to  conserve  energy,  they  cannot 
satisfy  occupants  and  conserve  energy. 
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2.2.2  Define  goals 

Once  the  Workgroup  has  identified  issues  with  the  current  BAS,  it  should 
define  goals  that  will  address  these  issues.  The  primary  goal  addressed  by 
this  implementation  plan  guidance  is  that  of  obtaining  Open  Systems,  i.e., 
that  the  building  and  UMCS  systems  shall  be  Open  implementations  of 
LonWorks®  in  accordance  with  the  DDC  and  UMCS  guide  specs.  This  goal 
helps  address  several,  but  not  all,  of  the  issues  identified  above.  In  particu¬ 
lar,  the  open  system  goal  largely  eliminates  problems  due  to  multiple,  in¬ 
compatible  proprietary  systems.  Other  goals  the  Workgroup  may  wish  to 
consider  are: 

•  System  Capabilities.  Identify  the  required  capabilities  of  the  system. 
For  example:  monitor  the  building-level  systems  and  generate  an  alarm 
when  something  is  wrong,  provide  scheduled  on/off  capability  for  all 
primary  equipment,  and  incorporate  preventive  maintenance  features 
such  as  pump  run  time  monitoring/logging. 

•  Training  and  Support.  A  successful  UMCS  will  require  a  support  struc¬ 
ture  and  qualified  staff.  Identifying,  establishing,  and  maintaining  a 
balance  of  in-house  and  external  support  may  be  a  challenge. 

•  Client  (Workstation)  Type.  Some  front  end  packages  provide  a  web  in¬ 
terface— sometimes  as  an  option  and  sometimes  as  an  integral  part  of 
the  software.  The  Workgroup  may  wish  to  identify  whether  a  web  inter¬ 
face  is  desired  and  practical  (e.g.,  whether  there  are  DOIM  require¬ 
ments  that  either  require  it  or  prohibit  it). 

2.2.3  Rank  goals 

After  identifying  the  goals,  the  Workgroup  may  choose  to  identify  the 
relative  importance  of  the  goals.  This  list  of  prioritized  goals  can  be  used 
during  the  development  of  the  source  selection  criteria  for  procurement  of 
the  UMCS  and  the  System  Integrator. 

2.2.4  Identify  obstacles 

Once  the  goals  for  the  system  are  identified  the  Workgroup  should  identify 
obstacles  that  might  impact  their  ability  to  realize  those  goals.  Some  pos¬ 
sible  obstacles  are: 

•  Cooperation  between  DPW  and  DOIM.  These  organizations  will  not 
necessarily  agree  on  the  best  solution  for  the  BAS.  For  example,  DPW 


ERDC/CERL  TR-08-12 


13 


might  want  a  web-based  front  end  while  DOIM  might  not  want  another 
web  server  on  the  network. 

•  Resources.  Is  there  sufficient  expertise  on  the  DPW  staff  or  otherwise 
available  to  enable  the  installation  to  operate  and  maintain  the  system? 
In  particular,  there  needs  to  be  a  long-term  commitment  of  personnel 
to  support  and  maintain  the  system. 

•  Commitment  of  Management.  Management  must  make  a  long-term 
commitment  to  establishing  a  BAS  that  meets  the  Workgroup- 
established  goals  for  these  goals  to  be  met. 

•  Training  Limitations.  To  properly  operate  and  maintain  the  system 
may  require  significant  training.  The  amount  of  training  time  and 
funds  available  may  impact  the  ability  to  train  DPW  staff  to  oper¬ 
ate/maintain  the  system. 

•  User  Buy-in  and  Support.  The  users  (the  DPW  and  maintenance  staff) 
must  buy-in  to  the  system  and  support  it  for  the  Workgroup- 
established  goals  to  be  met. 

•  Cost.  Systems  meeting  the  implementation  plan  defined  by  the  Work¬ 
group  may  be  more  costly  than  other  alternatives  in  the  short  term,  but 
having  a  single  coherent  and  working  system  will  prove  beneficial  in 
the  long  term.  If  cost  is  the  determining  factor  in  awarding  future  con¬ 
struction,  systems  that  are  incompatible  may  be  procured,  e.g.,  if  a  con¬ 
tractor  submits  a  “value  engineering”  proposal  and  it  is  awarded. 

2.3  Identify  approach  to  address  obstacles 

Once  the  Workgroup  has  identified  obstacles  that  may  hamper  the  execu¬ 
tion  of  the  plan,  it  should  identify  an  approach  to  addressing  these  obsta¬ 
cles.  In  general,  the  obstacles  will  fit  one  of  three  categories: 

1.  Fixable.  These  are  obstacles  that  the  Workgroup  can  eliminate  such  as 
policies  that  the  Workgroup  can  change  (or  get  someone  to  change)  or 
management  buy-in  that  the  Workgroup  can  obtain. 

2.  Addressable.  These  are  obstacles  that  the  Workgroup  cannot  change; 
however,  they  can  work  around  the  obstacles  in  some  fashion  such  as  by 
obtaining  exceptions  from  policy  or  by  including  specific  requirements  to 
be  met  by  the  system. 

3.  Unavoidable.  These  are  obstacles  that  the  Workgroup  cannot  change  or 
work  around  and  must  avoid.  Policies  that  do  not  offer  exceptions  or  hard 
limits  on  funding  are  two  examples. 
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The  Workgroup  should  identify  the  appropriate  actions  to  remove,  modify 
or  avoid  “fixable”  and  “addressable”  obstacles  and  begin  to  resolve  these 
issues.  “Unavoidable”  obstacles  should  be  carefully  documented  and  a 
means  to  avoid  them  should  be  identified. 

2.3.1  Develop  SOW(s)  to  obtain  external  technical  assistance 

The  UMCS  Workgroup  should  decide  if  external  assistance  is  needed  to 
proceed  with  development  of  the  implementation  plan  and  develop  state¬ 
ments  of  work  (SOWs)  to  obtain  this  assistance.  In  particular,  external  as¬ 
sistance  may  be  helpful  in  performing  a  site  survey  to  document  the  cur¬ 
rent  state  of  the  installation’s  BAS  and  DDC  systems  and  prioritize 
buildings  for  integration  to  the  new  UMCS. 

Appendix  A  (p  39)  contains  a  sample  SOW  for  this  type  of  assistance.  The 
Workgroup  should  feel  free  to  add  requirements  to  the  SOW  and/or  to 
perform  some  of  the  work  in-house.  Should  the  Workgroup  decide  to  pur¬ 
sue  external  assistance,  it  should  consider  contacting  the  local  Corps  Dis¬ 
trict  Office  or  the  Huntsville  Engineering  and  Support  Center  for  possible 
contracting  support. 

2.3.2  Coordinate  with  DOIM 

The  BAS  is  dependent  on  an  IP  network  and  personal  computers  (moni¬ 
toring  and  control  (M&C)  server(s),  client  workstations)  for  operation. 
This  makes  coordination  with  the  installation  Directorate  of  Information 
Management  (DOIM)  essential,  for  three  main  reasons: 

1.  On  most  installations,  any  computers  and  IP  networking  including  hard¬ 
ware/devices  connected  to  the  network  must  be  approved  by  the  DOIM. 

2.  There  are  mandatory  Army  and  Department  of  Defense  (DOD)  policies 
applicable  to  any  Army  information  system  (including  the  UMCS,  and  re¬ 
gardless  of  whether  they  utilize  the  basewide  LAN).  On  most  Army  instal¬ 
lations,  compliance  with  these  requirements  can  be  extremely  difficult 
without  DOIM  cooperation. 

3.  There  are  many  IT  issues  associated  with  the  BAS  for  which  the  DOIM  will 
be  the  resident  expert  and  can  provide  invaluable  assistance.  To  just  name 
a  few: 

a.  Installation,  operation,  and  maintenance  of  the  IP  network 


ERDC/CERL  TR-08-12 


15 


b.  Operation  and  maintenance  of  computer  hardware  (servers  and  work¬ 
stations) 

c.  Operation  and  maintenance  of  computer  software.  While  the  M&C 
software  will  be  very  application-specific  (and  outside  DOIM’s  area  of 
expertise),  it  generally  depends  on  other  software,  such  as  operating 
system,  database  servers,  web  servers,  browsers,  etc.,  all  of  which  are 
standard  packages  and  should  be  supported  by  DOIM. 

In  addition,  DOIM  can  provide  insight  into  the  availability  and  benefits  of 
alternative  networking  options  that  provide  promise  for  cost  effective  sys¬ 
tems  interfacing  and  integration.  Wireless  networking  options  (such  as 
WiFi  or  radio)  can  be  of  particular  value  when  integrating  remote  sites  or 
sites  with  other  restricted  access  to  the  LAN. 

The  first  step  in  coordinating  with  the  DOIM  is  to  explain  (in  terms  rele¬ 
vant  to  the  DOIM)  what  the  BAS  is: 

1.  The  BAS  will  use  two  distinct  networks: 

a.  Inside  buildings,  the  local  control  network  (as  installed  by  the  UFGS  23 
09  23  contractor)  will  be  a  TP/FT-10  network*  (shown  in  Figure  2)  us¬ 
ing  the  ANSI  709.1  protocol.  This  is  a  local  control  network  operating 
at  78  kbps,  not  an  IP  network.  The  nature  of  this  network  does  not  al¬ 
low  it  to  be  used  as  a  launching  point  for  attacks  against  the  IP  network 
and  should  therefore  not  be  of  concern  to  the  DOIM 

b.  Outside  the  buildings,  the  BAS  uses  an  IP  network,  ideally  one  based 
on  fiber  Ethernet,  although  any  media  supporting  IP  will  work.  This 
network  may  or  may  not  be  the  same  IP  network  as  the  DOIM  main¬ 
tained  basewide  LAN  and  is  referred  to  at  the  UMCS  Network  (or  the 
UMCS  IP  Network).  While  it  is  not  required  that  the  UMCS  use  the 
basewide  LAN,  its  use  is  strongly  encouraged  as  use  of  the  basewide 
LAN  will  greatly  facilitate  getting  LA  (Information  Assurance)  approval 
to  operate.  Note  that  much  of  this  network  is  fairly  static  in  nature  and 
(depending  on  DOIM  policy  and  DPW  requirements)  it  may  be  fairly 
easy  to  isolate  this  network  from  the  remainder  of  the  basewide  LAN  as 
discussed  below 

2 .  The  BAS  will  have  four  distinct  types  of  hardware : 


*  TP/FT  =  “twisted-pair/free  topology. 
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a.  Individual  buildings  will  have  specialized  embedded  control  hardware. 
These  devices  are  typically  highly  specialized  and  should  not  be  consid¬ 
ered  “IT  hardware.” 

b.  Each  building  will  have  a  CEA-852  “router,”*  which  tunnels  ANSI  709.1 
traffic  from  the  building  controllers  (devices  on  the  TP/FT-10  network) 
over  the  IP  network.  While  from  a  control  network  perspective, 

“router”  is  the  correct  term,  in  discussions  with  the  DOIM  it  is  very  im¬ 
portant  to  repeatedly  emphasize  that  these  are  not  IP  routers;  to  the  IP 
network  they  appear  as  end  devices.  This  device  is  often  referred  to  as 
the  Building  Point  Of  Connection  (BPOC)  shown  in  Figures  1  and  2. 

The  term  that  is  often  used  in  the  IT/  DIACAP  (Department  of  Defense 
Information  Assurance  Certification  and  Accreditation  Process)  world 
for  this  device  is  “IP  Platform  Interconnect,”  since  it  connects  a  “plat¬ 
form”  network  to  the  IP  network. 

c.  A  central  M&C  server,  which  is  a  standard  personal  computer  (PC) 
running  a  Windows  server  operating  system  (OS),  specific  application 
software,  and  will  communicate  with  the  CEA-852  routers  to  provide 
central  management  for  the  UMCS.  In  most  cases,  this  application 
software  will  be  dependent  on  standard  server  applications  such  as  a 
database  server  and/or  a  web  server.  Note  that  the  functionality  of  the 
M&C  server  may  be  spread  among  several  PCs.  The  M&C  server  will 
also  support  Operator  Workstation  (OWS)  clients. 

d.  OWS  clients.  These  are  standard  PCs,  which  may  or  may  not  be  run¬ 
ning  specific  application  software.  They  provide  the  user  interface  to 
the  BAS  for  the  system  operators. 

3.  Traffic  on  the  basewide  LAN  will  be  of  the  following  types: 

a.  Most  of  the  traffic  on  the  basewide  LAN  will  be  in  the  form  of  packets 
on  User  Datagram  Protocol  (UDP)  port  1628  and  1629,  which  are  reg¬ 
istered  with  the  Internet  Assigned  Numbers  Authority  (IANA)  for 
“LonTalk®  normal”  and  “LonTalk®  urgent.”  Most  of  this  traffic  will  be 
from  CEA-852  routers  (the  BPOCs)  in  buildings  to  the  M&C  server,  al¬ 
though  there  will  be  some  minor  and  infrequent  traffic  between  CEA- 
852  routers. 

b.  Traffic  between  the  M&C  server  and  client  OWSs.  While  the  exact  na¬ 
ture  of  this  traffic  is  vendor-dependent,  for  almost  all  vendors,  the 
M&C  server  will  act  as  a  web  server  and  the  OWS  clients  will  run  a 
standard  browser,  possibly  with  a  downloadable  Java  executable. 


*  CEA  =  “Consumer  Electronics  Association.” 
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c.  In  some  instances,  the  functionality  of  the  M&C  server  may  be  split 
among  several  machines.  For  example  one  machine  may  run  a  data¬ 
base  server,  another  a  web  server,  and  a  third  the  actual  M&C  vendor- 
specific  software.  In  this  case,  there  will  be  traffic  between  the  ma¬ 
chines,  usually  utilizing  standard  ports  appropriate  for  the  type  of  traf¬ 
fic  (e.g.,  database  traffic  on  port  1433).  Note  that  this  traffic  will  be  very 
local  to  the  M&C  servers  and  can  easily  be  isolated  from  the  rest  of  the 
LAN. 

d.  Occasional  configuration  traffic  between  the  M&C  server  and  the  CEA- 
852  routers.  The  CEA-852  routers  need  to  know  the  IP  addresses  of 
other  CEA-852  routers.  They  can  be  manually  configured  with  static  IP 
addresses;  however,  in  most  instances,  there  is  a  configuration  server 
application  that  runs  on  the  M&C  server  and  periodically  sends  up¬ 
dated  IP  address  information  to  the  CEA-852  routers. 

4.  There  are  three  possible  UMCS  IP  network  options  as  described/specified 
in  UFGS  25  10  10: 

a.  Shared  LAN  with  the  Basewide  IP  Network.  In  this  case,  UMCS  IP 
network  is  the  same  as  the  DOIM’s  basewide  IT  network  and  BAS  traf¬ 
fic  co-exists  with  other  IT  application  traffic.  It  is  suggested  that  the 
BAS  be  placed  on  a  separate  Virtual  Local  Area  Network  (VLAN)  to 
improve  security.  However,  the  M&C  server  and  OWSs  might  need  to 
be  exposed  to  the  rest  of  the  IT  LAN,  particularly  if  a  large  number  or 
mobile  (laptop)  OWSs  are  used. 

b.  Co-Located  IT  Hardware.  In  this  case,  the  UMCS  IP  Network  is  a 
physically  separate  network,  but  uses  spare  IT  hardware.  For  example, 
the  UMCS  may  run  on  spare  network  fibers  and  spare  IT  closet  rack 
space.  In  this  case,  consideration  needs  to  be  given  to  whether  there  is 
any  connection  at  the  M&C  server  between  the  UMCS  and  the  IT  LAN, 
and  if  so,  howto  secure  that  connection. 

c.  Completely  Independent  Network.  The  UMCS  has  no  common  hard¬ 
ware  or  space  with  the  IT  LAN.  Again,  consideration  needs  to  be  given 
to  whether  there  is  any  connection  at  the  M&C  server  between  the  BAS 
and  the  IT  LAN,  and  if  so,  how  to  secure  that  connection. 

Note  that  normally  Army  policy  dictates  that  DOIM  own/manage  all  IP 
networks  on  post.  This  means  that  even  if  an  independent  network  is  in¬ 
stalled  by  the  contractor,  the  DOIM  will  end  up  owning/ managing  the 
network  so  it  is  essential  that  the  network  be  installed  in  accordance  with 
DOIM  requirements. 
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It  is  recommended  that  the  installation  pursue  the  first  option,  where  the 
UMCS  uses  the  basewide  IT  LAN.  This  will  most  likely  be  the  lowest  cost 
option  since  the  contractor  will  not  have  to  install  significant  IT  hardware 
or  cabling.  In  addition,  there  are  many  IT-specific  issues  -  particularly  se¬ 
curity  -  that  the  DOIM  is  the  logical  resource  to  use  on  the  installation. 
The  only  reasons  to  recommend  against  this  option  is  if  the  DOIM  places 
too  many  restrictions  on  access  to  the  network,  or  equipment  on  the  net¬ 
work;  however  this  should  not  be  an  issue  if  UFGS  23  09  23  and  UFGS  25 
10  10  are  strictly  followed  since  they  greatly  limit  the  types  of  equipment 
that  may  be  used  in  the  buildings. 

Assuming  that  the  UMCS  network  utilizes  the  basewide  LAN,  there  are 
several  configuration  options  that  should  be  utilized  to  simplify  network 
management  and  provide  a  basic  level  of  security: 

•  Network  connections  between  the  network  drops  in  the  building 
(BPOCS)  and  the  M&C  server  should  be  isolated  on  a  separate 
VLAN.  A  VLAN  (Virtual  LAN)  is  a  networking  technology  where 
configuration  software  operating  in  IP  routers  and  IP  switches  al¬ 
lows  network  connections  to  be  grouped  into  separate  virtual  net¬ 
works  that  are  isolated  from  each  other.  This  isolation  provides  a 
level  of  security  (similar  to  a  firewall)  between  the  UMCS  and  the 
rest  of  the  basewide  LAN. 

•  Network  connections  between  the  M&C  server  and  client  worksta¬ 
tions  maybe  secured  via  several  mechanisms.  In  some  cases,  fixed, 
dedicated  workstations  may  be  used;  in  this  case,  these  machines 
should  be  on  the  same  VLAN  as  the  rest  of  the  UMCS  network.  In 
other  cases,  the  client  workstations  may  be  “normal”  PCs  on  the 
basewide  LAN;  in  this  case  a  firewall  should  be  employed  between 
the  M&C  server  and  the  basewide  LAN  to  permit  traffic  from  spe¬ 
cific  client  machines  only.  A  third  option  is  to  utilize  Virtual  Private 
Network  (VPN)  connections  between  client  machines  and  the  M&C 
server  in  conjunction  with  a  firewall;  this  option  permits  the  great¬ 
est  flexibility  in  client  workstations  while  maintaining  a  high  level 
of  security  between  the  UMCS  network  and  the  basewide  LAN. 

Another  area  of  coordination  with  the  DOIM  will  concern  operation  of  the 
servers  and  software  control  on  both  servers  and  clients.  The  DOIM  will 
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typically  have  specific  policies  and  procedures  in  place  for  the  support  of 
server  resources  on  post  and  should  generally  be  relied  on  to  provide,  op¬ 
erate,  and  maintain  the  M&C  server  machine(s).  One  possible  exception 
would  be  the  vendor-specific  M&C  software,  which  may  be  maintained  by 
the  DPW  (standard  packages,  such  as  a  database  server  and/or  web  server 
should  probably  be  maintained  by  the  DOIM).  Operating  systems  on  both 
client  and  server  machines  should  probably  be  maintained  by  the  DOIM; 
however  there  may  be  specific  requirements  for  UMCS  operation  that  the 
DOIM  should  be  aware  of. 

As  mentioned  above,  several  Army  policies  affect  the  UMCS  network,  with 
the  two  major  ones  being  DIACAP  and  Networthiness.  While  a  detailed 
description  of  these  is  outside  the  scope  of  this  document,  some  major 
points  are: 

•  The  DIACAP  (DOD  Information  Assurance  Certification  and  Accredita¬ 
tion  Process): 

o  Applies  to  any  Army  information  system,  regardless  of  how  imple¬ 
mented 

o  Is  designed  for  Army  wide,  centrally  deployed  systems  (i.e.,  Army 
Personnel  Management  System),  not  an  installation-specific  UMCS. 
o  Is  concerned  with  Information  Assurance  (IA) :  Continuity/Disaster 
recovery,  Security  Design,  Physical  environment,  Personnel,  Inci¬ 
dent  Management,  Authentication,  etc. 
o  Is  concerned  with  operations  and  policies/procedures  as  much  as 
with  installation 

o  May  require  each  UMCS  to  go  through  DIACAP  process  OR  it  may 
be  covered  under  an  existing  DOIM  DIACAP  (the  latter  is  highly 
desirable) 

o  Requires  every  UMCS  to  go  through  the  process  independently  -  an 
installation  may  not  reference  another  installation’s  DIACAP 
o  Is  very  time  consuming  and  expensive 

o  Is  probably  impossible  to  meet  without  close  coordination  with 
)OIM. 

The  key  point  here  is  that  by  far  the  easiest  solution  is  to  get  the 
UMCS  covered  under  an  existing  DOIM  DIACAP  for  the  basewide 
LAN. 
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•  Networthiness 

o  Is  required  of  any  system/component  used  on  an  Army  LAN. 
o  In  some  cases,  Certificates  of  Networthiness  for  identical  compo¬ 
nents  may  be  re-used  at  a  different  installation  -  an  installation 
may  reference  Networthiness  at  another  installation. 

Some  other  issues  to  discuss  with  the  DOIM  are: 

1.  If  the  DOIM  discourages  connection  to  the  basewide  IT  network,  what  are 
their  policies  regarding  other  independent  networks?  For  some  installa¬ 
tions,  other  (independent)  networks  may  be  prohibited,  in  which  case  the 
UMCS  must  be  on  the  basewide  IT  network. 

2.  What  are  their  requirements  for  allowing  a  system  to  connect  to  the 
basewide  network?  Is  DIACAP,  Networthiness,  or  other  certification  re¬ 
quired  and  if  so  how  should  the  installation  proceed?  What  restrictions 
would  the  DOIM  place  on  the  M&C  server  and  client  OWSs?  The  least  ex¬ 
pensive  and  time  consuming  approach  is  to  include  the  UMCS  as  an  ad¬ 
dendum  to  an  existing  DIACAP. 

3.  Access  and  interconnections  (if  any)  between  the  UMCS  network  and  the 
basewide  LAN.  While  the  BPOCs  do  not  need  a  connection  to  the  IT  net¬ 
work,  there  are  sound  reasons  for  allowing  the  OWSs  to  be  on  the  IT  net¬ 
work  (which  implies  that  either  they  are  on  both  the  UMCS  network  and 
the  IT  network,  or  (more  likely)  that  the  M&C  server  is  on  both  LANs): 

a.  Use  of  the  IT  network  for  the  OWSs  allows  tremendous  flexibility  for 
the  location  of  the  OWSs,  particularly  where  the  OWS  client  is  a 
browser  with  a  Java  executable.  In  this  case,  almost  any  PC  on  the  IT 
network  becomes  a  potential  OWS. 

b.  Use  of  IT  resources  from  the  OWS  and/or  M&C  server,  e.g.,  e-mail, 
M&C  software  updates,  searching  on-line  documentation,  etc. 

4.  Inbound  access  to  the  UMCS  network  from  off-post.  Although  not  specifi¬ 
cally  required  by  the  guide  specifications,  many  commercial  M&C  software 
packages  have  the  capability  of  connecting  with  an  OWS  over  the  Internet. 
If  coordinated  and  implemented  with  DOIM  this  may,  for  example,  allow 
O&M  staff  to  connect  from  home  to  perform  troubleshooting.  This  raises 
obvious  security  concerns  and  should  not  be  considered  without  consulta¬ 
tion  with  the  DOIM. 

5.  Use  of  wireless  networking,  Virtual  Private  Networks  (VPNs),  or  other  in¬ 
formation  technologies  to  access  “hard-to-reach”  points  on  the  BAS,  for 
example,  a  utility  substation  with  metering  that  is  not  on  the  basewide 
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LAN  could  conceivably  be  reached  over  the  Internet  with  a  dedicated  VPN 
or  wirelessly. 

6.  Any  firewalls  employed  to  restrict  access  on  the  UMCS  network,  or  be¬ 
tween  the  UMCS  network  and  the  basewide  LAN.  Even  if  the  UMCS  net¬ 
work  is  totally  independent,  the  DOIM  should  be  consulted  to  provide  se¬ 
curity  information  regarding  the  need  for  firewalls. 

Appendix  B  (p  47)  contains  a  set  of  “FAQs”  that  may  be  useful  in  answer¬ 
ing  questions  DOIM  may  have. 

The  WorkGroup  and  DOIM  may  choose  to  develop  a  memorandum  of  un¬ 
derstanding  (MOU)  or  similar  document  describing  DOIM  expectations 
and  requirements.  The  MOU  might  include  verbiage  to  be  added  to  instal¬ 
lation-specific  UMCS  specification,  DDC  specification,  and  other  BAS- 
related  project  specifications  (such  as  in-house  contracts).  Appendix  C  (p 
52)  includes  considerations  for  the  creation  of  a  MOU  with  DOIM. 

2.3.3  Define/develop  acceptance  methodology  and  checklists 

To  successfully  integrate  a  building  system  into  a  UMCS,  the  building  DDC 
system  must  be  verified  that  it  is  ready  for  integration.  Therefore  an  accep¬ 
tance  methodology  is  needed  for  construction  Quality  Verification  (QV) 
staff  and  O&M  staff  to  use  in  verifying  that  the  building  systems  have  met 
the  specification  requirements.  The  appendices  to  the  guide  specifications 
contain  checklists  that  must  be  submitted  by  the  Contractor’s  quality  con¬ 
trol  (QC)  representative.  While  these  checklists  can  be  used  as  a  baseline 
for  QV  staff  they  are  not  a  complete  acceptance  methodology. 

Appendix  I  (p  91)  includes  a  scaled-down  draft  of  a  LonWorks  compliance 
assessment  tool,  which  is  a  checklist  that  can  be  used  as  one  tool  in  the  de¬ 
velopment  of  an  installation  specific  acceptance  methodology.  The  actual 
tool,  available  at  the  website  listed  below,  is  a  spreadsheet  that  contains 
comments,  hyperlinks,  definitions,  and  examples  that  are  intended  to  aid 
the  novice.  The  intent  of  the  checklist  is  to  gage  the  readiness  of  building 
DDC  systems  for  interface  with  a  UMCS,  without  actually  performing  the 
interface,  in  part  because  Army  installations  often  procure  DDC  systems 
but  do  not  always  immediately  interface  them  to  a  UMCS.  The  latest  ver¬ 
sion  of  this  checklist  is  available  at  the  ERDC-CERL  BAS  Team  website  at 
https://eko.usace.army.mil/fa/bas/. 


ERDC/CERL  TR-08-12 


22 


2.3.4  Define  training  requirements 

The  UMCS  Workgroup  should  identify  training  needed  to  support  the 
BAS. 

O&M  staff  and  system  operators  are  targeted  in  the  UMCS  and  DDC  guide 
specs  where  the  installing  Contractor  is  required  to  provide  training.  Al¬ 
though  the  intent  of  the  training  requirements  in  the  specifications  is  to 
achieve  a  degree  of  proficiency  in  system  operation  and  maintenance,  it 
should  not  be  assumed  that  this  training  is  sufficient.  Individual  installa¬ 
tions  and  staff  members  may  have  specific  training  needs.  The  training  re¬ 
quirements  in  these  specifications  can  be  edited  to  meet  specific  needs. 
Beyond  this,  it  is  likely  that  a  degree  of  formal  and  specialized  training  will 
be  needed  to  meet  the  complex  demands  of  microprocessor-based  controls 
including  DDC  hardware  and  software.  Possible  training  options  include: 

1.  Vendor-Specific  DDC  Guide  Spec  Draining.  Most  construction  contracts, 
specifically  those  that  originate  at  the  Corps  District  level,  include  contrac¬ 
tor-provided  training  requirements.  UMCS  Workgroup  and  O&M  staff 
should  review  and  help  edit  the  training  requirements/specs  during  the 
design  phase. 

2.  Vendor-Specific  UMCS  Guide  Spec  Training.  The  contractor-provided 
training  on  the  UMCS  front-end  Monitoring  and  Control  (M&C)  software 
is  extensive  and  specified  in  great  detail.  Still,  additional  training  may  be 
warranted  depending  on  the  extent  that  the  system  operator(s)  will  be  in¬ 
volved  with  the  operation  and  management  of  the  UMCS.  Individuals  that 
will  perform  system  integration  functions  should  receive  formal  vendor 
training  such  as  that  offered  at  the  vendor’s  formal  training  facility. 

3.  Proponent  Sponsored  Engineer  Corps  Draining  (PROSPECT)  Course. 
“HVAC  Control  Systems:  Design  and  Quality  Verification.”  (Control  No. 
340)  provides  instruction  on  LonWorks®  control  systems  specific  to  the 
requirements  in  both  the  DDC  and  UMCS  guide  specs.  Although  designers 
and  Quality  Verification  staff  are  targeted,  O&M  staff  would  also  benefit 
from  this  course.  The  course  schedule  is  available  from  the  “USACE  Learn¬ 
ing  Center”  through  URL:  http://pdsc.usace.army.mil. 

4.  Vendor  Draining.  Most  BAS  and  DDC  system  manufacturers  offer  product 
specific  training  at  the  manufacturer’s  formal  training  facility.  This  type  of 
training  can  provide  in-depth  familiarity  with  specific  products  including 
software  tools.  Training  on  the  Network  Configuration  Tool  (NCT)  and  on 
the  UMCS  M&C  software  would  be  of  value  particularly  in  the  case  where 
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the  installation  has  selected  a  single- vendor  NCT  and  M&C  for  its 
basewide  BAS/UMCS.  Note  that  both  of  these  pieces  of  software  are  speci¬ 
fied  in  the  UMCS  guide  spec. 

2.3.5  Develop  IDG  requirements  and  in-house  LonWorks®  specs 

The  UMCS  Workgroup  should  update  the  IDG  to  accommodate  applicable 
elements  of  the  Implementation  Plan.  Develop,  coordinate,  and  distribute 
abbreviated  LonWorks®  specs/requirements  for  use  by  in-house  contract¬ 
ing  elements  such  as  Job  Order  Contract  (JOC),  Plans  and  Programs,  etc. 
that  can  be  appended  to  or  used  as  part  of  any  SOW  used  to  specify  BAS- 
related  work  performed  by  in-house  elements.  Appendix  D  (p  54)  contains 
sample  IDG  requirements. 

2.4  Identify  building  integration  approach 

Although  the  UMCS  may  be  procured  separately  from  building  integration 
services,  the  approach  used  to  obtain  building  integration  may  greatly  im¬ 
pact  the  procurement  of  the  UMCS.  This  is  particularly  true  if  some  type  of 
long-term  contracting  mechanism  will  be  used  for  both  the  initial  UMCS 
procurement  and  subsequent  system  integration  services.  This  approach 
should  therefore  be  identified  as  early  in  the  process  as  possible  -  ideally 
before  the  UMCS  procurement. 

Regardless  of  the  approach,  a  final  goal  is  to  have  a  UMCS  and  system  in¬ 
tegration  approach  in-place  so  that  as  new  building  level  DDC  systems  are 
competitively  procured  they  can  be  integrated  with  the  basewide  UMCS. 

The  following  sections  discuss  integration  approaches  and  contracting 
mechanisms.  Table  1  summarizes  the  contracting  mechanisms  that  can  be 
used  with  the  different  integration  approaches. 

2.4.1  General  system  integration  approaches 

Ideally,  the  installation  will  have  a  specific  individual  responsible  for  the 
integration  of  all  new  buildings  into  the  UMCS.  This  person  -  the  System 
Integrator  (SI)  -  will  be  familiar  with  the  system  as  well  as  the  installa¬ 
tions  procedures  for  integration  and  would  therefore  be  able  to  efficiently 
integrate  new  buildings.  While  it  may  be  possible  to  get  near  this  ideal 
through  a  long-term  contract  of  some  sort,  it  is  not  always  feasible  (in 
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which  case,  the  integration  may  have  to  be  performed  on  a  case-by-case 
basis).  In  general,  the  integration  approach  will  be  one  of  the  following: 

•  “In-House”  SI 

•  Long  Term  Contract  for  system  integration 

•  Case-by-Case  Integration  (Using  Separate  Dedicated  Contract) 

•  Case-by-Case  (Using  Combined  Building  Contract  and  Integration  Ser¬ 
vices). 

The  following  sections  describe  each  of  these  approaches  in  detail. 


Table  1.  Possible  contracting  mechanisms  by  integration  approach. 


System  Integration  Approach 

In  House 

Long-Term 

Contract 

Case-by-Case 

Separate 

Contractor 

Case-by-Case, 
Building  Contractor 

tuo  c 

.E  i 

Local  office 

Yes 

Unlikely1 

Yes 

Unlikely2 

ESPC 

Yes 

No 

No 

No 

o  c 

CD  CD 

£  f= 

District  IDIQ 

No 

Yes 

Yes 

No 

r-  O 

O  ^ 

o  :> 

Center  IDIQ 

No 

Yes 

Yes3 

No 

District  MILCON 

No 

No4 

No4 

Yes 

^-Most  installation  contracting  offices  are  resistant  to  this  type  of  contract 

2The  building  contract  is  usually  awarded  by  a  Corps  district,  not  the  local  contracting  office 
3Via  MIPR  of  funds  from  the  district  to  Huntsville  to  award 

4Not  as  part  of  the  district  awarded  MILCON  job  but  the  district  can  MIPR  funds  to  be  used 
by  one  of  the  other  methods. 

2.4. 1.1  “In-House”  system  integrator 


The  installation  hires  or  trains  an  SI.  This  is  the  preferred/ideal  approach. 
By  having  the  SI  on  staff,  the  installation  benefits  from  maximum  flexibil¬ 
ity  in  the  use  of  the  SI.  The  installation  does  not  have  to  issue  task  orders 
or  a  new  contract  to  get  systems  integrated  and  can  benefit  from  ongoing 
system  maintenance.  Contracting  approaches  that  fit  this  category  include: 

•  hiring  or  training  a  Government  employee 

•  hiring  a  contractor  through  an  existing  services  contract 

•  establishing  a  service  contract 

•  obtaining  services  though  another  mechanism  -  such  as  an  Energy 
Savings  Performance  Contract  (ESPC).  Since  an  ESPC  contract  is  gen¬ 
erally  for  a  long  period  and  generally  includes  more  than  System  Inte¬ 
gration  service,  caution  should  be  exercised  with  this  approach  to  be 
sure  the  installation  will  be  able  to  effectively  work  with  the  ESPC  con- 
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tractor.  See  section  24.2.2  Energy  saving  performance  contracting 

(ESPC). 

A  key  aspect  to  this  approach  is  that  the  system  integration  services  are 
provided  at  a  fixed  cost.  However,  it  is  important  to  realize  that  this  fixed 
cost  generally  equates  to  a  certain  number  of  man-hours,  so  the  amount  of 
time  it  takes  to  integrate  a  building  and  the  number  of  buildings  that  can 
be  integrated  will  depend  on  the  System  Integrator’s  workload.  The  pur¬ 
chase  of  products  needed  to  perform  the  integration  is  still  dependent  on 
the  buildings  that  are  integrated,  but  this  amount  is  small.  If  this  approach 
is  used,  it  may  be  in  the  best  interest  of  the  installation  to  require  that  the 
building  DDC  system  contractor  provide  the  Building  Point  of  Connection 
(Router)  to  remove  this  cost  from  the  SI. 

2.4. 1.2  Long  term  contract 

With  this  approach  the  installation  establishes  an  Indefinite  Deliv¬ 
ery/Indefinite  Quantity  (ID/IQ)  or  similar  contract  with  an  SI.  This  ap¬ 
proach  allows  the  installation  to  obtain  integration  services  from  the  same 
entity  as  each  new  building  system  is  installed,  but  generally  will  require 
issuing  task  orders  for  the  integration,  which  may  take  additional  time.  A 
key  aspect  of  this  is  to  obtain  uniform  pricing  per  system  for  the  integra¬ 
tion.  For  example,  the  DDC  guide  specification  (UFGS  23  09  23)  contains 
standard  sequences;  the  Indefinite  Delivery/Indefinite  Quantity  (IDIQ) 
contract  should  specify  pricing  for  integrating  these  standard  systems. 

2. 4.1.3  Case-by-case  integration  (using  separate  dedicated  contract) 

With  this  approach,  whenever  a  new  building  is  procured,  a  separate 
specification  for  integration  of  the  building  to  the  UMCS  is  issued.  Main¬ 
taining  this  as  a  separate  contract  (rather  than  including  it  with  the  build¬ 
ing  DDC  system  specification)  reduces  the  competitive  advantage  that 
could  be  generated  by  combining  the  two  tasks  (see  below).  Since  the 
original  installer  of  the  UMCS  system  will  be  most  familiar  with  the  sys¬ 
tem,  they  may  in  practice  have  a  small  advantage  in  winning  the  integra¬ 
tion  contract,  but  this  is  a  small  task  (dollar-wise)  compared  with  the 
building  DDC  system.  However,  anyone  familiar  with  the  UMCS  system 
software  can  perform  this  integration  so  proprietary  procurement  can  be 
avoided.  In  this  approach,  tasks  other  than  integration  such  as  system  up¬ 
grades  and  maintenance  need  to  be  accomplished  under  a  separate  con- 
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tract.  As  in  the  combined  building  and  integration  contract,  if  the  integra¬ 
tion  contract  ends  up  being  awarded  to  the  building  DDC  contractor,  extra 
care  needs  to  be  taken  to  ensure  that  the  building  contractor  does  not  “cut 
corners”  in  the  integration. 

2.4. 1.4  Case-by-case  (using  combined  building  contract  and  integration 

services) 

With  this  approach,  the  integration  of  the  building  into  the  UMCS  is  in¬ 
cluded  in  the  building  specification  contract;  a  single  contractor  performs 
both  tasks.  This  can  give  a  competitive  advantage  to  the  original  UMCS 
system  installer/manufacturer  since  they  will  generally  be  able  to  integrate 
the  building  more  inexpensively  than  could  the  competition.  This  can  be 
particularly  problematic  when  the  contractor  “cuts  corners”  or  provides 
“value  engineering”  to  reduce  the  level  of  openness  in  the  building  DDC 
system  since  an  open  building  (necessary  for  integration  when  the  con¬ 
tracts  are  separate)  is  typically  more  costly  than  a  “closed”  building.  A 
combined  contractor  can  install  and  integrate  a  “closed”  building  more 
cheaply  than  the  same  contractor  could  install  and  integrate  an  open 
building.  While  this  is  less  of  a  problem  with  the  “case-by-case  integration 
using  a  separate  dedicate  contract”  approach,  it  may  become  problematic 
when  the  contracts  are  combined  because  this  advantage  depends  not  only 
on  the  integration,  but  also  on  the  building  DDC  system,  which  can  be  a 
large  (i.e.,  costly)  project.  This  is  the  least  desirable  approach  and  is  dis¬ 
couraged. 

2.4. 1.5  Selection  of  a  system  integration  approach 

The  system  integration  approach  that  the  Workgroup  decides  to  pursue 
will  depend  on  many  factors,  including  the  contracting  options  and  fund¬ 
ing  available  to  the  installation.  The  “In-House  SI”  and  “Long  Term  Con¬ 
tract”  approaches  may  (but  need  not)  be  funded  by  the  installation.  In 
both  cases,  the  agency  issuing  the  contract  to  install  a  building  system  can 
likely  set  aside  funds  to  pay  for  integration  services.  For  example,  if  the 
Corps  District  awards  a  Military  Construction  (MILCON)  project  for  a 
building  DDC  system,  and  the  installation  has  an  ID/IQ  contract  in  place 
for  SI  services,  the  District  can  MIPR  funds  to  the  installation  to  award  an 
integration  task  on  the  ID/IQ.  Appendix  G  (p  75)  contains  an  example 
process  (courtesy  of  Fort  Bragg)  that  describes  the  steps  to  be  taken  to  ac¬ 
complish  integration  by  MIPRing  Military  Construction,  Army  (MCA) 
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funds  from  Savannah  District  to  Huntsville  for  award  of  a  task  order 
against  an  existing  Huntsville  IDIQ  contract.  With  the  two  “Case-by-Case” 
approaches,  the  agency  issuing  the  contract  to  install  the  building  system 
must  both  fund  the  integration  and  include  integration  requirements  in 
the  contract(s)  awarded  by  the  issuing  agency.  The  workgroup  should 
identify  the  approach  as  part  of  their  basewide  BAS  planning  process. 

The  open  system  specified  in  UFGS  25  10  10  and  UFGS  23  09  23  provides 
some  flexibility  in  contracting  Systems  Integration  and  protection  against 
being  “locked  in”  to  a  specific  company  or  individual.  Should  the  need 
arise  the  UMCS  and/or  the  Systems  Integrator  can  be  replaced  without  re¬ 
placing  the  database  or  any  of  the  building-level  systems  installed  under 
UFGS  23  09  23.  Replacing  an  SI  with  another  SI  with  knowledge  of  the 
UMCS  can  be  done  with  minimal  effort.  Replacing  the  UMCS,  however, 
requires  not  only  the  procurement  of  new  software  but  the  labor  to  set  the 
new  software  up  to  replace  the  old  UMCS,  and  thus  so  should  be  avoided 
when  possible. 

If  the  long-term  contract  integration  option  is  pursued,  three  main  options 
should  be  considered  on  contract  expiration: 

1.  Keep  the  current  SI  (renew  the  contract).  If  the  installation  is  satisfied  with 
the  SI  and  the  UMCS,  this  option  is  preferred;  it  provides  continuity  and 
allows  the  installation  to  continue  a  good  relationship  with  the  SI. 

2.  Issue  a  contract  to  a  new  SI  and  keep  the  current  UMCS.  If  the  UMCS  is 
satisfactory  but  the  installation  is  not  satisfied  with  the  SI,  this  option  pro¬ 
vides  an  opportunity  to  work  with  a  different  SI  while  maintaining  the  in¬ 
vestment  in  (money,  time,  and  effort)  already  put  into  the  UMCS. 

3.  Procure  a  new  UMCS  and  issue  a  contract  to  a  new  SI.  If  the  UMCS  is 
functioning  and  installation  personnel  are  satisfied  with  it,  this  option  is 
discouraged  due  to  the  cost  of  procuring  a  new  UMCS.  If  the  UMCS  is  un¬ 
satisfactory,  this  option  may  provide  an  opportunity  to  “upgrade”  to  a 
UMCS  the  installation  will  be  satisfied  with. 

2.4.2  Contracting  mechanisms 

While  evaluating  these  integration  approaches,  the  Workgroup  should  also 
consider  the  available  contracting  options.  Some  options  are: 

•  Local  Contracting  Office 

•  Energy  Saving  Performance  Contracting  (ESPC) 
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•  Corps  District  ID/IQ  Contracts 

•  Centers  of  Expertise  ID/IQ  Contracts. 

The  following  sections  describe  these  approaches  in  detail. 

2.4.2. 1  Local  contracting  office 

Depending  on  the  workload  and  capabilities  of  the  installation  Contracting 
Directorate,  the  local  contracting  office  may  be  able  to  help  establish  a 
long-term  contract  for  integration  services.  Example  statements  of  work 
(contained  in  Appendices  E  and  F)  will  be  useful  in  discussions  with  the 
local  Contracting  office.  There  is  the  advantage  of  working  with  people  in 
the  local  area  and  developing  relationships  and  conveying  an  understand¬ 
ing  of  the  needs,  but  set  asides  and  small  business  rules  may  restrict  op¬ 
tions  to  smaller  companies  with  unknown  skills.  It  is  best  to  provide  a  very 
detailed  statement  of  work  (SOW)  that  defines  all  the  specialized  require¬ 
ments  and  skill  sets  of  the  contractor.  The  Workgroup  member(s)  should 
be  a  part  of  the  evaluation  board  to  ensure  the  contractor  selected  is  fully 
qualified  and  capable. 

2. 4. 2. 2  Energy  saving  performance  contracting  (ESPC) 

ESPC  is  only  one  of  a  large  set  of  performance  type  contracts  where  the 
contractor  provides  the  initial  investment  and  gets  paid  back  from  savings. 
It  may  be  difficult  to  calculate  the  savings  from  building  integration  into  a 
UMCS,  and  to  quality  for  ESPC,  a  project  must  show  energy  savings.  If 
considering  using  an  ESPC  for  the  UMCS  installation  and  operation,  it 
may  be  best  to  add  the  integration  services  to  the  statement  of  work  as 
well.  Although  ESPCs  are  widely  thought  to  be  the  answer  to  under-funded 
installations,  this  funding  mechanism  does  have  some  disadvantages. 

Most  importantly,  finance  charges  are  paid  throughout  the  life  of  the  con¬ 
tract  and  the  installation  loses  some  control  over  the  buildings  included  in 
the  scope.  Changes  in  building  use  or  configuration  that  affect  the  planned 
savings  may  cause  conflicts  with  the  contract  in  terms  of  the  shared  finan¬ 
cial  savings.  In  the  worst  case,  installations  may  be  required  to  pay  con¬ 
tractors  “estimated”  savings;  savings  that  would  have  accrued  to  the  con¬ 
tractor  if  the  government  had  not  changed  building  use  or  configuration. 

In  some  cases,  the  government  has  determined  that  it  is  advantageous  to 
buy  the  contract  out.  If  the  installation  can  obtain  integration  and  mainte¬ 
nance  services  for  both  the  UMCS  and  the  integrated  buildings  and  does 
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not  object  to  potentially  losing  a  certain  amount  of  direct  control  over  the 
BAS,  this  approach  may  work  well. 

2.4.2. 3  Corps  District  ID/IQ  contracts 

Some  Corps  Districts  may  have  qualified  vendors  under  an  ID/IQ  contract. 
They  also  may  have  contracting  services  that  will  issue  the  documentation 
to  procure  a  system  integrator  for  the  installation.  Each  District  is  unique 
in  this  aspect. 

2. 4.2. 4  Centers  of  Expertise  ID/IQ  contracts 

Most  Corps  of  Engineers  Centers  of  Expertise  have  a  collection  of  vendors 
under  contract  with  specialized  skills  that  match  up  with  and  support  the 
Center’s  mission.  The  Center  of  Expertise  for  Utility  Monitoring  and  Con¬ 
trol  System  (UMCS)  is  Huntsville’s  Engineering  and  Support  Center. 
Huntsville  has  ID/IQ  contracts  with  highly  skilled  and  experienced  UMCS 
vendors.  Generally  speaking,  there  are  many  advantages  using  the  ID/IQ 
contracting  vehicles:  pre-selected  vendors  with  focused  skills,  many  years 
of  experience,  a  long  track  record  of  success,  no  protests,  great  incentive  to 
partner  with  and  please  the  customer,  and  good  leverage  for  problem  reso¬ 
lution.  The  engineers  at  the  Centers  are  familiar  with  the  new  LonWorks® 
specifications  and  can  provide  design  services,  technical  support  during 
installation,  review  of  submittals,  and  testing.  This  work  for  the  installa¬ 
tions  is  funded  through  fees  from  the  customers.  The  Centers  are  reim¬ 
bursed  based  on  the  level  of  effort  requested. 

2.4.3  System  integrator  considerations 

It  is  important  to  consider  the  needs  of  the  installation  when  evaluating 
potential  system  integration  approaches  and  System  Integrators.  For  ex¬ 
ample,  the  installation  may  be  comfortable  performing  maintenance  on 
the  system  and  may  only  need  the  SI  to  perform  actual  integration  or  they 
may  want  the  SI  to  perform  maintenance  as  well.  In  general,  the  exact  re¬ 
quirements  placed  on  the  SI  will  vary  from  place  to  place,  but  in  general, 
some  items  to  consider  are: 

l.  Training.  Integrators  that  work  for/represent  manufacturers  of  software 
for  HVAC  systems  should  have  formal  training  on  the  software.  Independ¬ 
ent  or  third-party  integrators  that  use  other  software  (i.e.,  software  not 
specifically  made  for  HVAC  systems,  but  for  control  systems  in  general 
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such  as  industrial  controls)  should  have  training  in  the  software  they  are 
using. 

2.  Experience  with  LonWorks®  (proven  past  performance  including  experi¬ 
ence  with  UFGS  23  09  23  /  UFGS  25 10 10  integration  projects).  This  no¬ 
tably  includes  use  of  a  LonWorks  Network  Services  (LNS )  Network  Con¬ 
figuration  Tool  and  LNS  plug-ins. 

3.  Experience  with  other  proprietary  protocols  and  systems  that  pre-exist 
on  site  should  the  Workgroup  decide  that  the  integration  of  these  systems 
into  the  new  UMCS  is  desired. 

4.  Familiarity  with  DOIM  and  network  security  requirements.  Prior  experi¬ 
ence  dealing  with  these  requirements  would  be  beneficial,  but  few  integra¬ 
tors  may  have  this  experience. 

5.  Knowledge  of  the  building-level  (UFGS  23  09  23)  contractor’s  require¬ 
ments  that  will  impact  integration  such  as: 

a.  Scheduling  -  detailed  familiarity  with  these  requirements 

b.  Alarm  handling  -  detailed  familiarity  with  these  requirements 

c.  Point  Schedules  -  how  to  use  them. 

2.4.4  Acceptance  testing 

Testing  can  be  complex  and  detailed,  and  can  require  an  experienced  field 
technician  or  engineer.  The  UMCS  system  integrator  can  be  a  useful  part¬ 
ner  in  working  with  UFGS  23  09  23  (or  building-level)  contractors,  by  per¬ 
forming  submittal  reviews,  particularly  in  the  case  of  the  Points  Schedule 
drawing  and  in  the  case  of  the  control  sequences  such  as  alarm  handling 
and  scheduling  that  are  highly  dependent  on  ANSI  709.1  and  the  use  of 
SNVTs.*  It  is  important  to  realize,  though,  that  building-level  system  ac¬ 
ceptance  must  be  accomplished  prior  to  any  integration  activities  so  as  to 
avoid  potential  finger  pointing  in  the  event  there  are  problems  with  the 
building-level  system. 

2.4.5  Develop  system  integration  SOW(s) 

2.4.5. 1  Overview 

Based  on  the  selected  system  integration  approach,  the  Workgroup  should 
develop  one  or  more  SOW(s)  for  UMCS  Systems  Integrator  (SI)  support  to 


*  Standard  Network  Variable  Type.  A  standard  format  type  used  to  define  data  for  an  ANSI  709.1 
LONWORKS  network 
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procure  services  either  via  long  term  contract  (preferred/  recommended) 
or  on  a  case-by-case  basis  (where  there  are  two  options  as  previously  de¬ 
scribed).  Alternatively,  SI  services  will  be  performed  in-house,  in  which 
case  a  contract  is  likely  not  needed;  however,  arrangements  must  be  made 
to  define  and  formalize  this  SI  mechanism. 

Appendix  E  (p  58)  and  Appendix  F  (p  70)  contain  two  example  Systems 
Integration  SOWs.  These  SOWs  are  further  described  below  and  should  be 
used  with  caution  and  only  as  applicable  to  the  selected  integration  ap¬ 
proach.  Guidance  including  notes  and  bracketed  options  for  developing  a 
project  specific  SOW  is  contained  in  the  sample  SOWs.  More  recent  ver¬ 
sions  of  the  SOWs  may  be  available  at:  https://eko.usace.army.mil/fa/bAS/. 

2.4.5. 2  UMCS  system  administrator ,  technical  support  representative, 

and  system  integrator  SOW 

The  intent  of  this  SOW  (Appendix  E,  p  58)  is  to  get  System  Integrator  on 
staff  who  will  establish  and  create  a  UMCS  in  accordance  with  the  re¬ 
quirements  and  intent  of  UFGS  25  10  10.  The  SOW  defines  scope  and  re¬ 
quirements  to  develop  and  document  a  System  Integration  Methodology, 
develop  and  document  a  System  Operation  Methodology,  manage  and  op¬ 
erate  the  UMCS  according  to  the  Operation  Methodology,  and  to  provide 
DPW-embedded  maintenance  support.  This  SOW  contains  a  placeholder 
where  the  ‘UMCS  DDC Integration  SOW’,  described  below,  can  be  in¬ 
cluded. 

2.4.5.3  UMCS  DDC  integration  SOW 

This  SOW  (Appendix  F,  p  70)  defines  scope  and  requirements  to  integrate 
LNS-based  LonWorks  building  control  system(s)  into  an  LNS-based  Lon- 
Works  UMCS. 

2.5  Document  the  implementation  plan 

The  UMCS  Workgroup  should  document  the  target  basewide  BAS  and  de¬ 
scribe  how  to  obtain  it.  The  plan  should  include  the  results  of  the  previous 
steps  and  guide  the  execution  of  the  procurement  and  expansion  of  the 
UMCS.  This  plan  should  be  considered  a  living  document  and  should  be 
updated  periodically  as  lessons  are  learned  from  its  execution.  It  should  be 
as  complete  as  possible  and  should  define  BAS  goals,  features,  functions, 
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requirements,  needed  support,  integration  approach,  contracting  method¬ 
ology,  and  a  path  forward. 

Once  the  implementation  plan  is  documented  it  should  be  reviewed  and 
coordinated  with  the  Workgroup  as  well  as  any  other  individuals  or  of¬ 
fices/agencies  who  will  be  affected  by  it.  Appendix  H  (p  78)  contains  a 
sample  plan.  Some  topics  to  include  in  the  plan  are: 

1.  UM CS  Workgroup.  Provide  a  list  of  members. 

2.  Purpose/Pi'oblem.  Describe  the  current  BAS  situation  including  a  descrip¬ 
tion  of  the  existing  systems  and  problems  that  need  to  be  ad¬ 
dressed/overcome. 

3.  Goals  and  Benefits.  Describe  the  goal(s)  and  benefits.  Focus  on  the  big  pic¬ 
ture  functions  and  capabilities  of  the  system. 

4.  BAS  Description/ Characteristics.  The  plan  should  describe  characteris¬ 
tics,  features,  and  functions  of  the  proposed  BAS  in  more  detail  than  that 
in  the  Goals/Benefits  section.  This  might,  for  example,  address/include: 

a.  The  need  for  a  computer  operator  workstation  located  in  the  Energy 
Manager’s  office,  one  in  each  Work  Leader’s  office,  one  in  each  shop 
common  area 

b.  The  capability  to  set  up  and  change  schedules  from  each  operator 
workstation  (OWS) 

c.  Other  energy  management  functions  such  as  monitoring  and  subse¬ 
quent  reports  for  specific  systems  or  subsystems 

d.  The  need  for  certain  types  of  alarms  and  for  alarms  to  be  directed  to 
specific  shops/individuals 

e.  Building-level  DDC  system  functions/features.  UFGS  23  09  23  con¬ 
tains  specific  detailed  sequences  of  operation;  if  the  installation  desires 
“standard  deviations”  from  those  sequences  (e.g.,  pneumatic  actuators, 
tighter  sensor  tolerances,  etc.),  then  they  should  be  documented  here 
and/or  in  the  installation  design  guide  (IDG). 

f.  Training  and  certain  types  of  technical  assistance. 

5.  Support  Structure.  The  plan  should  define  support  requirements  and  a 
proposed  support  structure.  This  includes  an  internal  support  structure 
along  with  internal/external  technical  and  contracting  support.  The  sup¬ 
port  structure  should  include  the  designation  of  responsible  parties  for  all 
aspects  related  to  ongoing  support  of  the  BAS.  It  should  also  point  out  the 
need  for  coordination  with  specific  in-house  entities  such  as  DOIM  and 
Contracting  office(s): 

a.  UMCS  Workgroup 


ERDC/CERL  TR-08-12 


33 


b.  UMCS  System  Integrator  (likely  a  Contractor,  but  possibly  in-house 
staff) 

c.  DOIM  Liaison 

d.  Computer  System  Administrator  (Attends  to  computer  issues:  Operat¬ 
ing  system  upgrades,  users,  etc.) 

e.  UMCS  System  Administrator 

f.  Laptop  Manager  (hardware/ software  management) 

g.  UMCS  Operator(s) 

h.  DDC  Specialists  (hardware/ software  experts) 

i.  Building  Acceptance  point  of  contact  (POC) 

j.  In-house  contracting  mechanisms/entities. 

In  regard  to  the  in-house  contracting  mechanisms/entities,  the  plan 
should  identify  and  list  each  in-house  contracting  mechanism  that 
might  be  involved  in  the  procurement  of  BAS  elements  (such  as  JOCs, 
Plans  and  Programs,  etc.),  regardless  of  who  procures  them.  Open, 
non-proprietary,  interoperable  systems  must  include  at  least  minimal 
specifications  to  ensure  compatibility  of  these  systems  with  the 
LonWorks®  UMCS.  Coordination  of  these  requirements  with  the  in- 
house  contracting  entities  is  necessary  to  help  ensure  that  all  procured 
systems  meet  these  requirements. 

6.  Path  Forward.  The  plan  should  describe  subsequent  steps  and  expecta¬ 
tions. 

2.6  Execute  UMCS  procurement 


Once  the  implementation  plan  is  complete,  the  Workgroup  can  proceed 
with  the  procurement  of  a  UMCS  as  described  in  the  plan. 
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3  Conclusion 

This  work  has  identified  and  documented  an  overall  strategy  for  site- 
specific  implementation  of  an  Open  basewide  BAS  based  on  LONWORKS® 
technology  and  American  National  Standards  Institute  (ANSI)  communi¬ 
cations  standard  709.1  where  the  BAS  consists  of  a  basewide  Utility  Moni¬ 
toring  and  Control  System  (UMCS)  that  is  interoperable  with  multi-vendor 
LONWORKS®  direct  digital  control  (DDC)  systems. 

While  no  two  Army  installations  are  identical  in  their  BAS  needs  and  re¬ 
quirements,  the  overall  implementation  process  is  much  the  same  across 
installations.  It  is  strongly  recommended  that  each  Army  installation  de¬ 
velop  and  document  a  BAS  implementation  plan  and  maintain  this  plan  as 
a  living  document  in  coordination  with  the  installation’s  IDG.  It  is  benefi¬ 
cial  for  the  installation  to  create  a  workgroup  minimally  consisting  of 
members  from  the  DPW  including  the  Energy  Manager,  maintenance 
shop(s),  and  Engineering  staff,  DOIM,  and  the  Corps  of  Engineers  District 
and  Area  Offices.  The  workgroup  should  create  plan  and  guide  the  imple¬ 
mentation  where  key  elements  of  the  implementation  include: 

•  Identify  a  mechanism  and  approach  though  which  the  installation  can 
obtain  system  integration  services  where  third  party  DDC  systems  are 
integrated  with  the  UMCS  front-end. 

•  Coordinate  and  work  with  the  DOIM  on  information  assurance  and  se¬ 
curity  requirements.  In  particular,  The  UMCS  will  need  a  DIACAP  (cer¬ 
tification)  and  this  is  best  accomplished  as  an  addendum  to  (under)  an 
existing  DIACAP. 

•  Make  sure  Points  Schedule  drawings  are  developed  for  and  used  on  all 
DDC  projects. 

•  Take  time  to  perform  DDC  system  quality  verification  and  acceptance 
activities  especially  for  the  first  few  projects  so  as  to  help  ensure  that 
your  DDC  Contractors  understand  the  project  requirements. 

While  BAS  technology  can  be  complex,  successful  implementation  is  pri¬ 
marily  a  matter  of  familiarity  with  and  exposure  to  the  specifications  and 
requirements. 
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Acronyms  and  Abbreviations 


Term 

SDellout 

A/E 

architect/engineer 

AFB 

Air  Force  Base 

ANSI 

American  National  Standards  Institute 

ASC 

application  specific  controller 

ASHRAE 

American  Society  of  Heating,  Refrigerating,  and  Air-Conditioning  Engineers 

BAS 

Building  Automation  System 

BPOC 

Building  Point  of  Connection 

BRAC 

Base  Realignment  and  Closure 

CEA 

Consumer  Electronics  Association  (CEA) 

CEERD 

U.S.  Army  Corps  of  Engineers,  Engineer  Research  and  Development  Center 

CERL 

Construction  Engineering  Research  Laboratory 

CO 

Contracting  Officer 

COE 

Corps  of  Engineers 

COR 

Contracting  Officer's  representative 

COTR 

Contracting  Officer's  Technical  Representative 

CSMA/CD 

carrier  sense  multiple  access  with  collision  detection 

DDC 

direct  digital  control 

DHCP 

Dynamic  Host  Configuration  Protocol 

DIACAP 

Department  of  Defense  Information  Assurance  Certification  and  Accreditation  Process 

DITSCAP 

DOD  Information  Technology  Security  Certification  and  Accreditation  Process 

DOD 

Department  of  Defense 

DOIM 

Directorate  of  Information  Management 

DPW 

Directorate  of  Public  Works 

DSN 

Domain,  Subset,  Node 

DX 

Directory  of  Expertise 

EBI 

Enterprise  Buildings  Integrator 

ECB 

Engineering  and  Construction  Bulletin 

ECIP 

Energy  Conservation  Investment  Program 

EIA 

Electronic  Industries  Alliance 

EMCS 

Energy  Monitoring  and  Control  System 

ERDC 

Engineer  Research  and  Development  Center 

ESPC 

Energy  Savings  Performance  Contract 

FAQ 

frequently  asked  questions  (FAQ) 

FMD 

Facilities  Maintenance  Division 

GPPC 

General  Purpose  Programmable  Controller 

GUI 

graphical  user  interface 

HNC 

Huntsville  Center,  Alabama  (HNC) 
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Term 

SDellout 

HQ 

headquarters 

HQUSACE 

Headquarters,  U.S.  Army  Corps  of  Engineers 

HTML 

hypertext  markup  language 

HTTP 

hypertext  transfer  protocol 

HVAC 

heating,  ventilating,  and  air-conditioning 

I/O 

input/output 

IA 

Information  Assurance 

IANA 

Internet  Assigned  Numbers  Authority 

IATO 

Interim  Authority  To  Operate 

ID/IQ 

indefinite  delivery  indefinite  quantity 

IDC 

Indefinite  Delivery  Contract 

IDG 

Installation  Design  Guide 

IDIQ 

Indefinite  Delivery/Indefinite  Quantity 

IM 

instant  messaging 

IMCOM 

Installation  Management  Command 

IMO 

Information  Management  Office 

IP 

Internet  protocol 

IT 

Information  Technology 

JCI 

Johnson  Controls,  Inc. 

JOC 

Job  Order  Contract 

LAN 

Local  Area  Network 

LCS 

LONWORKS  Control  Station 

LDP 

local  display  panel 

LEED 

Leadership  in  Energy  and  Environmental  Design 

LNS 

LonWorks  Network  Services 

M&C 

monitoring  and  control 

MCA 

Military  Construction,  Army 

MCX 

Mandatory  Center  of  Expertise 

MILCON 

Military  Construction 

MIPR 

Military  Interdepartmental  Purchase  Request 

MOU 

memorandum  of  understanding 

NAC 

Network  Access  Control 

NACLC 

National  Agency  Check  with  Local  Agency  and  Credit  Check 

NOT 

Network  Configuration  Tool 

NTP 

Notice  To  Proceed 

O&M 

operations  and  maintenance 

01 

Operator  interface 

OMA 

Operations  and  Maintenance,  Army 

OMB 

Office  of  Management  and  Budget 

OMD 

Operations  Maintenance  Division 

OS 

operating  system 
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Term 

SDellout 

OSI 

Open  Systems  Interconnection 

OWS 

Operator  Work  Station 

P&P 

Plans  and  Programs 

PC 

personal  computer 

PDA 

personal  digital  assistant 

PDF 

Portable  Document  Format 

POC 

point  of  contact 

PROSPECT 

Proponent  Sponsored  Engineer  Corps  Training 

PVT 

Performance  Verification  Test 

QC 

quality  control 

QV 

Quality  Verification 

RFP 

request  for  proposal 

ROM 

read  only  memory 

SAS 

Savannah  District 

SCADA 

Supervisory  Control  And  Data  Acquisition 

SI 

System  Integrator 

SIM 

System  Integration  Methodology 

SNMP 

Simple  Network  Management  Protocol 

SNVT 

Standard  Network  Variable  Type 

SOW 

statement  of  work 

SQL 

structured  query  language 

SSBI 

Single  Scope  Background  Investigation 

TCP 

Transmission  Control  Protocol 

TP/FT 

twisted-pair/free  topology 

TR 

Technical  Report 

TSR 

technical  service  representative 

UDP 

User  Datagram  Protocol 

UESC 

Utility  Energy  Services  Contract 

UFGS 

Unified  Facilities  Guide  Specification  (UFGS) 

UMCS 

Utility  Monitoring  and  Control  System 

URL 

Universal  Resource  Locator 

USACE 

U.S.  Army  Corps  of  Engineers 

VLAN 

Virtual  Local  Area  Network 

VPN 

Virtual  Private  Network 

XI F 

external  Interface  File 

XML 

Extensible  Markup  Language 
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Appendix  A:  Control  Systems  Assessment 
Statement  of  Work 

The  following  is  a  sample  statement  of  work  (contract)  (SOW)  used  for  the 
implementation  of  the  guidelines  in  this  report  at  several  installations.  For 
use  at  a  single  installation,  this  SOW  must  be  tailored  to  refer  to  installa¬ 
tion  specific  requirements  and  to  refer  to  only  one  installation. 

STATEMENT  OF  WORK 
ARCHITECT-ENGINEER  SERVICES  FOR 
IMCOM  BUILDING  AUTOMATION  SYSTEM  IMPLEMENTATION  PLANS 
FOR  FORT  BRAGG,  NORTH  CAROLINA,  FORT  LEE,  VIRGINIA, 

FORT  BLISS,  TEXAS,  AND  FORT  HOOD  TEXAS 

1.  REFERENCE.  Indefinite  Delivery  Contract  (IDC).  This  task  order  will 
be  issued  under  IDC  W912HN-05-D-0017. 

2.  OVERVIEW.  This  work  is  in  association  with  a  joint  effort  among 
ERDC-CERL,  Huntsville  Engineering  and  Support  Center,  and  Savannah 
District  funded  by  Installation  Management  Command  (IMCOM)  to  define 
a  methodology  for  the  development  of  a  basewide  open  BAS  plan  based  on 
LonWorks®  technology  and  ANSI  standard  709.1  as  specified  in  UFGS  25 
10  10  and  23  09  23  where  the  BAS  consists  of  a  basewide  UMCS  that  is  in¬ 
teroperable  with  multi-vendor  LonWorks®  DDC  systems. 

3.  DESCRIPTION  OF  WORK.  This  SOW  covers  all  services  to  perform 
site  visits  to  four  installations:  Fort  Bragg,  North  Carolina;  Fort  Bliss, 
Texas;  Fort  Lee,  Virginia;  and  Fort  Hood  Texas;  and  to  prepare  resulting 
reports  based  on  the  site  visits.  This  will  include  pre-site  visit  planning  and 
coordination  with  all  team  members,  LonWorks®  site  assessment,  on-site 
coordination  assistance/participation,  development  of  site-specific  Im¬ 
plementation  Plan  verbiage,  tables,  and  data,  in  an  Assessment  Report. 

The  objective  is  for  the  architect/engineer  (A/E)  to  perform  a  site-specific 
assessment  of  LonWorks®  BASs  and  BAS  components  to  determine  if  and 
to  what  extent  the  installations’  BASs  are  in  compliance  with  the  require- 
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ments  defined  in  UFGS  25  10  10  and  UFGS  23  09  23.  The  A/E  shall  pro¬ 
vide  recommendations  on  how  the  installation  can  proceed  to  obtain  a 
basewide  UMCS  in  accordance  with  UFGS  25  10  10  and  23  09  23  including 
an  assessment  of  local  contractors’  capability  to  support  UFGS  25  10  10 
and  23  09  23  where  the  goal  is  to  assist  each  installation  prepare  for  and 
achieve  state  of  the  art,  maintainable,  operable,  and  cost  effective 
basewide  BAS.  For  the  purposes  of  this  SOW,  a  BAS  is  defined  as  a  group 
of  DDC  systems  interconnected  via  a  communications  network  (such  as 
IP)  with  a  front-end/UMCS  and  a  standalone  DDC  system  is  defined  as 
one  that  is  not  connected  to  a  front-end/UMCS. 

4.  REQUIRED  A/E  SERVICES.  The  A/E  shall  perform  the  services  in¬ 
dicated  in  the  Statement  of  Work.  These  services  will  be  provided  in  three 
distinct  phases: 

•  Pre-site  visit  planning 

•  Pre-site  visit  telephone  calls  to  site  staff 

•  Site  visits 

•  Assessment  Reports. 

4.1.  Pre-site  visit  activities. 

a.  Participate  in  a  conference  call  with  SAS,  HNC,  ERDC-CERL  and 
POC(s)  from  each  site  to  review  the  technical  requirements  of  this  SOW. 
The  purpose  will  be  to  go  over  the  thrust  of  the  effort,  to  identify  all  initial 
points  of  contact,  and  to  solidity  the  details  of  the  site  visit  and  the  reports. 
Anticipated  level  of  effort:  0.5  days. 

For  each  installation,  the  following  shall  be  accomplished: 

b.  Contact  the  Government  supplied  site  POC  to  schedule  a  site  assess¬ 
ment  visit  with  appropriate  personnel  to  assist  in  performing  the  tasks  de¬ 
scribed  in  the  SOW.  Personnel  may  include;  the  Energy  Manager,  DPW 
Chief  of  O&M  Division,  DPW  Chief,  O&M  Production  Control,  DPW  Shop 
Foreman,  DPW  Work  Leader,  Engineering  Services  Branch  Chief,  and 
DPW  HVAC/Controls  staff,  DPW  A-76  Contractor  (IAP)  HVAC/Controls 
staff.  Notify  the  Government  of  scheduled  site  visit(s).  For  Fort  Hood  re¬ 
lated  work  the  A/E  need  only  speak  and  meet  with  Mr.  Dick  Strohl.  Antici¬ 
pated  level  of  effort:  0.5  days  per  site. 
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c.  Obtain  as  much  advance  information  listed  in  exhibit  A  as  is  possible  via 
telephone  calls  in  advance  of  site  visits.  For  Fort  Hood,  the  A/E  need  not 
execute  the  items  in  Exhibit  A.  Anticipated  level  of  effort:  3  days  per  site. 

4.2.  Site  visits.  For  each  the  installation,  the  following  shall  be  accom¬ 
plished: 

Perform  site  visits  to  identify  and  quantify  the  installation’s  BASs.  The  intent 
is  to  get  a  working  sense  from  a  long  term  planning  perspective  of  the  state  of 
the  installation’s  BASs  and  to  obtain  lessons  learned.  The  information  in  Ex¬ 
hibit  A  shall  be  obtained.  For  Fort  Hood,  the  A/E  need  only  update  the  re¬ 
port:  SITE  SURVEY  AND  DATA  COLLECTION  UTILITY  MONITORING 
AND  CONTROL  SYSTEM  (UMCS)  MASTER  PLAN  FORT  HOOD,  TEXAS  in¬ 
cluding;  Chapter  1.  General  Description,  Chapter  2.2  Review  of  UMCS  Cur¬ 
rently  Installed  at  Fort  Hood,  and  Chapter  3.  Buildings  For  Future  UMCS 
Master  Plan.  The  Fort  Hood  work  shall  include  new  LonWorks®  control  sys¬ 
tem  additions  to  the  existing  SITE  SURVEY.  Anticipated  level  of  effort:  5  days 
per  site. 

4.3.  Assessment  Report. 

a.  For  each  installation,  after  the  site  visit,  the  A/E  shall  provide  a  finished 
Assessment  Report  documenting  the  site  assessment  and  providing  all  in¬ 
formation  described  above  including  names  of  individuals  that  the  A/E 
spoke  and  met  with.  The  assessment  shall  include  the  recommendations 
on  how  the  installation  could  proceed  to  obtain  a  basewide  UMCS  in  ac¬ 
cordance  with  UFGS  25  10  10  and  23  09  23,  including  the  assessment  of 
local  contractors’  capability  to  support  UFGS  25  10  10  and  23  09  23.  In  the 
case  of  Fort  Hood,  the  A/E  need  only  update  the  SITE  SURVEY  report. 
Anticipated  level  of  effort:  2  days  per  site. 

b.  For  each  installation,  the  A/E  shall  schedule  a  conference  call  to  present 
and  discuss  the  Assessment  Report  to  ERDC-CERL,  Savannah  District, 
and  Huntsville  Engineering  and  Support  Center.  Both  parties  will  discuss 
the  issues  and,  if  necessary,  attempt  to  resolve  unsettled  issues  that  may 
arise.  Anticipated  level  of  effort:  0.5  days  per  site. 

4.4.  Notes  and  Discussions.  The  A/E  shall  take  notes  and  prepare  minutes 
for  all  meetings  and  conferences  attended  during  the  project.  Minutes 
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shall  be  signed  by  the  project  manager  and  furnished  to  the  Savannah  Dis¬ 
trict  project  engineer  within  7  calendar  days  after  the  meeting/conference 
for  concurrence  and  distribution.  The  A/E  shall  provide  a  written  record  of 
all  significant  discussions  and  telephone  conversations  that  the  firm’s  rep¬ 
resentatives  participate  in,  on  matters  relative  to  the  project.  Records  will 
be  provided  within  7  calendar  days  of  the  conversations.  Anticipated  level 
of  effort:  included  in  above  tasks. 

5.  SUBMITTALS  AND  PERFORMANCE  SCHEDULE. 

5.1  All  deliverables  will  be  provided  electronically  to  the  Savannah  District 
project  engineer.  Deliverables  include: 

•  Notes  and  minutes  of  all  conferences  -  included  in  Assessment  Report. 

•  Record  of  significant  discussions  and  conversations  -  included  in  As¬ 
sessment  Report. 

•  Assessment  Report  and  update  of  the  Fort  Hood  SITE  SURVEY  report 
-  within  7  calendar  days  of  completion  of  the  site  visit. 

5.2.  Performance  Periods  and  Submission  Schedules.  The  performance  pe¬ 
riods  and  submission  schedules  for  each  item  are  indicated  below.  All  ac¬ 
tivities  must  be  completed  by  30  July  2007. 


Item 

Due  after  Notice  To 
Proceed  (NTP) 
(calendar  days) 

a.  Notice  to  Proceed 

... 

b.  Conference  call  (A/E,  CERL,  SAS,  HNC) 

8 

c.  Site  visit  1  complete 

As  mutually  agreed 

d.  Submit  Site  1  Assessment  Report 

14  days  after  item  c. 

e.  Site  1  conference  call  (A/E,  CERL,  SAS,  HNC) 

7  days  after  item  d. 

f.  Site  visit  2  complete 

As  mutually  agreed 

g.  Submit  Site  2  Assessment  Report 

14  days  after  item  f. 

h.  Site  2  conference  call 

7  days  after  item  g. 

i.  Site  visit  3  complete 

As  mutually  agreed 

j.  Submit  Site  3  Assessment 

14  days  after  item  i. 

k.  3  conference  call 

7  days  after  item  j. 

6.  AUTHORIZED  CHANGES.  The  A/E  shall  accept  instructions  only 
from  the  Contracting  Officer  or  his  duly  appointed  representative.  Coordi¬ 
nation  of  routine  technical  matters  with  Corps  of  Engineers  personnel  will 
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be  accomplished  through  the  project  engineer,  Lucie  Hughes,  CESAS-EN- 
EP.  Direct  requests  from  other  agencies  should  be  forwarded  to  the  Project 
Engineer  for  consideration. 

7 .  EXHIBITS. 

A.  Installation  Assessment  Information 

EXHIBIT  A 

Installation  Assessment  Information 

BAS  System  List:  List  of  LonWorks®  and  non-  LonWorks®  BASs,  both 
existing  and  under  construction.  Where  available  provide  diagrams  in 
Adobe®  Portable  Document  Format  (PDF)  or  other  electronic  format 
Total  number  of  buildings  connected  to  a  BAS,  as  a  total  number  and  as  an 
estimated  percentage  of  the  installation. 

BAS  System  details:  For  each  BAS  on  the  BAS  System  List  provide  the  fol¬ 
lowing  information: 

Operator  interface  (01)  system  name  and  manufacturer.  Provide  version 
number  if  available  and  applicable  particularly  where  it  might  be  of  inter¬ 
est  as  part  of  a  basewide  systems  integration  plan.  For  example,  if  the  01  is 
widely  used  or  applied  or  is  LNS  compatible.  Number  of  buildings  con¬ 
nected  to  the  BAS,  as  a  total  number  and  as  an  estimated  percentage  of  the 
installation  or  other  indication  of  the  system  size  at  contractor’s  discretion 

■  Functions  and  Utilization.  Provide  a  summary  of  functions  that 
the  BASs  perform  (alarms,  scheduling,  trending,  etc.)  particu¬ 
larly  those  functions  of  interest  and  value  to  the  DPW.  Provide 
an  indication  of  the  degree  and  type  of  utilization  of  the  BASs  by 
the  DPW  and  others. 

■  Unusual  types  of  equipment  monitored  or  controlled  such  as 
lighting  systems,  energy-monitoring-only  systems,  access  con¬ 
trol  systems,  etc.  where  the  intent  is  obtain  an  awareness  of  any 
special  needs  or  requirements  that  the  installation  might  have 
beyond  ordinary  HVAC  control. 

■  For  each  building  connected  to  the  BAS  provide: 

°  Building  numbers,  building  group,  or  area.  The  intent, 
within  time  and  resource  constraints,  is  to  obtain  as  much 
detail  as  is  reasonably  available. 
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°  Product  (manufacturer)  name  for  DDC  controls  contained 
within/under  the  BASs.  The  intent  is  to  obtain  insight  into 
the  variety  and  types  of  DDC  hardware  at  the  installation.  As 
part  of  this,  of  interest  is  the  relative  quantities  of  ASCs  ver¬ 
sus  General  Purpose  Programmable  Controllers  (GPPCs).  In¬ 
teraction  with  a  knowledgeable  individual  in  one  of  the  DPW 
shops  can  facilitate  this  effort. 

°  Installing  controls  contractor  name.  (Also  see  related  re¬ 
quirement  later  in  the  Exhibit). 

■  For  LonWorks®  BASs,  provide  an  assessment  of  each  ones 

compliance  with  UFGS  25  10  10  and  answer  the  following  ques¬ 
tions: 

0  What  media  type  was  used? 

0  Are  UFGS  25  10  10  compliant  CEA  709.1  to  IP  (CEA  852) 
routers  used? 

0  Are  gateways  (such  as  NAE’s,  JACE’s,  or  other  similar  prod¬ 
ucts)  used?  If  yes,  list  gateways  including  product  name. 

0  Are  alarms  implemented  in  accordance  with  UFGS  25  10  10 
and  in  compatible  accordance  with  UFGS  23  09  23? 

0  Is  (occupancy)  scheduling  accomplished  in  compatible  ac¬ 
cordance  with  UFGS  23  09  23? 

0  Were  licensed  copies  of  an  NCT  submitted?  How  many  cop¬ 
ies?  Where  are  they? 

b.  What  DDC  and  BAS  preference(s)  does  the  installation  have  such  as 
a  particular  brand  or  type  of  control  (such  as  application  specific 
controller  [ASC]  versus  General  Purpose  Programmable  Controller 
[GPPC]).  Any/all  insights  are  useful. 

c.  Description  of  how  the  various  BASs  are  integrated  such  as;  Are 
there  multiple  front-ends,  are  any  on  the  basewide  LAN,  are  there 
gateways  at  the  building  level,  are  different  manufacturers  systems 
integrated  together,  are  there  BASs  that  are  contain  control  net¬ 
works  at  the  building  level,  but  are  not  interfaced  to  an  OWS,  are 
any  BASs  configured  for  dial-up-only  access,  etc. 

d.  Summary  of  BASs  and  buildings  that  are  based  on  LonWorks® 
technology. 

e.  Summary  of  and  UFGS  25  10  10  compatible  front-ends  that  have  a 
software  gateway  to  the  existing  BAS.  (e.g.,  a  Johnson  Controls,  Inc. 
(JCI)  Network  Application  Engine  (NAE)  with  an  NIE  to  an  existing 
Metasys  BAS) 

f.  For  LonWorks®  building-level  systems  (that  may  or  may  not  be 
part  of  a  BAS,  i.e.,  these  can  be  “standalone”  systems),  identify 
compliance  with  UFGS  23  09  23  for  a  representative  sample  of  not 
less  than  three  UFGS  23  09  23  systems,  in  each  case  installed  by 
different  contractor.  Provide  the  following: 

■  Assessment  of  submittals: 
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°  Were  Points  Schedule  drawing(s)  submitted?  Obtain  and 
submit  copies  of  the  Points  Schedules.  Provide  an  opinion  as 
to  whether  the  Points  Schedules  meet  the  intent  and  re¬ 
quirements  of  UFGS  23  09  23. 

0  Was  an  LNS  database  submitted? 

0  Were  external  Interface  File  (XIF)  files  submitted? 

0  Were  LNS  plug-ins  submitted?  Are  LNS  plug-ins  available 
(from  the  manufacturer)  for  the  installed  devices? 

0  If  programmable  controllers  were  used  was  the  program¬ 
ming  software  submitted?  Was  the  application  program 
submitted? 

■  Are  the  building  systems  in  accordance  with  the  UFGS  23  09  23 
LonWorks®  requirements?  Provide  an  overall  answer  to  this 
question  as  well  as  specific  answers  to  the  following: 

0  Was  the  “scheduling  sequence”  accomplished  in  accordance 
with  UFGS  23  09  23 

0  Are  alarms  implemented  in  accordance  with  UFGS  23  09  23? 
0  Was  a  critical  alarm  handler  provided? 

0  Is  there  a  System  Scheduler? 

0  Are  all  devices  connected  to  a  TP/FT-10  building  control  net¬ 
work? 

■  What  O&M  tools  (such  as  an  NCT)  were  provided  or  are  other¬ 
wise  available?  Do  the  tools  meet  UFGS  23  09  23  and  25  10  10 
requirements?  For  TP/FT-10  networks  are  there  network  inter¬ 
face  jacks  available  as  specified  and  are  there  dongles  available 
for  workstation  (laptop)  connection?  Are  there  software  pack¬ 
ages  or  tools  other  than  an  NCT? 

■  Perform  a  network  analysis  of  one  building’s  (or  more  if  time 
permits)  TP/FT-10  network  and  compare  the  results  to  the  re¬ 
quirements  of  UFGS  23  09  23  and  the  Points  Schedule. 

g.  Identify  and  list  local  vendors/contractors  (name,  phone,  e-mail, 
website)  who  do  work  at  the  installation. 

■  If  available,  provide  an  indication  of  the  extent/magnitude  of 
their  work  experience  at  the  installation  such  as  how  many  jobs 
(such  as  many,  few,  one),  job  size  (numerous  systems,  one  or 
two  buildings),  and  approximately  how  long  have  they  been  do¬ 
ing  work  at  the  installation. 

■  Provide  an  assessment  of  their  capability  to  install  and  support 
LonWorks®  in  accordance  with  UFGS  23  09  23  and  25  10  10, 
particularly  LNS. 

■  What  UMCS/DDC  brands/product  lines  does  the  contractor 
support?  Are  the  products  LNS  compatible? 

■  How  much  experience  does  each  Contractor  appear  to  have  with 
UFGS  23  09  23/25  10  10  systems? 

■  Assess  Contractor’s  potential/capabilities  to  implement  UFGS 
23  09  23  scheduling  and  alarm  sequences. 
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■  What  Contractor  preferences  does  the  installation  have?  Are  any 
contractors  on  a  non-compliance  or  “problem”  list?  If  yes,  indi¬ 
cate  why  if  the  reason  is  known  and  publicly  available  non¬ 
sensitive  information. 


ERDC/CERL  TR-08-12 


47 


Appendix  B:  DOIM  Frequently  Asked 
Questions  (FAQs) 

1.  What  is  ANSI  709.1? 

The  “Control  Network  Protocol  Specification”  ANSI  709.1  is  an  ANSI  stan¬ 
dard  communications  protocol  (including  Open  Systems  Interconnection 
[OSI]  layers  1  through  6,  originally  developed  by  the  Echelon  Corporation 
(Echelon  refers  to  it  as  “LonTalk®”)  and  widely  used  for  data  communica¬ 
tion  between  devices  designed  for  monitoring  and  control  of  building 
automation  systems. 

2.  What  bandwidth  requirement  and  traffic  profile  does  it  have? 

The  average  bandwidth  requirements  are  very  low,  with  occasional  (still 
quite  modest)  peaks.  Almost  all  traffic  will  be  between  a  single  building 
point  of  connection  (BPOC)  and  a  master  front  end  monitoring  and  con¬ 
trol  (M&C)  computer,  and  it  is  meaningful  to  discuss  network  bandwidth 
requirements  at  two  points: 

•  Inside  the  building,  traffic  is  on  a  dedicated  carrier  sense  multiple  ac¬ 
cess  with  collision  detection  (CSMA/CD)  network  (not  part  of  the  IP 
network)  operating  at  78  kbps.  This  inherently  limits  the  bandwidth  on 
the  IP  network  side. 

•  The  greatest  bandwidth  requirement  will  be  at  the  central  M&C  server, 
where  the  average  requirement  can  be  estimated  based  on  two  factors: 
o  Communications  from  the  buildings.  While  this  traffic  increases 

with  the  number  of  buildings  each  building  contributes  only  a  small 
amount  to  the  bandwidth  usage. 

o  Communication  between  the  software  server  and  clients.  The 
bandwidth  usage  will  depend  on  the  software  used  and  the  number 
of  workstations.  This  communication  is  more  bandwidth  intensive 
than  communications  with  the  building  systems,  but  depends  on 
the  number  of  OWSs,  not  the  number  of  buildings.  The  small 
amount  of  data  exchanged  (say  20  pieces  of  data  for  a  typical  “re¬ 
fresh”  between  a  client  and  the  server)  results  in  a  low  bandwidth 
utilization. 
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Note  that,  by  the  very  nature  of  building  automation  systems,  most  data 
packets  will  be  very  small;  the  data  portion  of  the  IP  packet  will  generally 
be  on  the  order  of  64  bytes  or  less. 

3.  Does  it  use  standard  protocols,  including  TCP,  IP,  DHCP,  and 
SNMP?* 

Yes.  ANSI  709.1  is  a  standard  protocol  including  OSI  layers  1  through  6; 
however  it  can  run  on  an  IP  network  via  a  tunneling  protocol,  CEA-852.  As 
far  as  the  IP  network  is  concerned,  the  basewide  network  will  consist  of 
these  852  “routers,”  one  (or  two  if  redundant  servers  are  installed)  central 
monitoring  and  control  (M&C)  computers,  and  additional  computers  act¬ 
ing  as  clients  to  the  central  M&C  computer.  Specific  installations  may  in¬ 
crease  the  number  of  server  computers.  For  example,  some  vendors  use 
Microsoft  Structured  Query  Language  (MS-SQL)  for  an  underlying  data¬ 
base  and/or  use  a  web  server  for  client  access  and  these  components  may 
be  distributed  among  multiple  servers;  these  installations  will  have  addi¬ 
tional  server  -  server  traffic  on  standard  ports.  These  devices  will  all  use 
TCP/IP  and  (optionally,  at  the  DOIM’s  discretion)  Dynamic  Host  Configu¬ 
ration  Protocol  (DHCP). 

Many  (if  not  all)  client  -  server  communication  will  use  HTTP  on  port  80. 

4.  Will  there  be  unmanaged  web  servers  on  the  network? 

No.  The  BAS  specified  under  UFGS  23  09  23  and  UFGS  25  10  10  does  not 
use  HTML,  XML,  Web  Services,  or  http  to  communicate  among  devices. 
Depending  on  the  vendor  selected  under  the  UMCS  contract  according  to 
the  UMCS  specification,  the  front-end  M&C  server  will  probably  use  a 
managed  web  server  to  support  operator  workstations.  However,  this  will 
be  a  single  (or  perhaps  a  small  number  of  co-located)  machines  that  can  be 
located  in  a  secure  area.  If  this  is  a  concern,  the  DOIM  representative  on 
the  BAS  Working  Group  should  help  to  define  additional  requirements 
and/or  restrictions  on  the  UMCS  Contractor  to  ensure  that  any  web  serv¬ 
ers  will  meet  DOIM  requirements. 


*  TCP  =-  “Transmission  Control  Protocol";  IP  =  “Internet  Protocol”;  DHCP  =  “Dynamic  Host  Configuration 
Protocol";  and  SNMP  =  “Simple  Network  Management  Protocol.” 
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5.  What  other  protocols  are  used? 

The  normal  sharing  of  data  packets  between  BPOCs  located  at  the  build¬ 
ings  and  the  M&C  server  is  tunneled  via  CEA-852  on  IANA-approved  ports 
UDP  1628  and  UDP  1629. 

6.  Does  it  use  broadcasts? 

The  CEA-852  routers  do  not  use  broadcasts— they  tunnel  ANSI  709  pack¬ 
ets  as  point-to-point  packets  to  other  CEA-852  routers.  The  M&C  server 
and  client  computers  will  run  a  standard  operating  system  that  may  use 
broadcasts  (but  this  is  not  specific  to  the  control  system  and  DOIM  is  used 
to  dealing  with  such  operating  systems).  There  may  be  limited  numbers  of 
broadcasts  during  the  initial  configuration  of  the  CEA-852  routers;  how¬ 
ever  it  is  not  necessary  that  these  broadcasts  be  forwarded  by  IP  routers. 

7.  What  are  the  IT  connectivity  requirements? 

Each  building  will  require  a  single  network  drop  and  (preferably)  static  IP 
address  for  each  of  CEA-852  router.  For  large  buildings,  it  is  possible  that 
two  or  more  CEA-852  routers  will  be  used,  in  which  case  more  network 
drops  and  IP  addresses  will  be  required.  Point-to-point  links  will  be  im¬ 
plemented  between  these  852  routers  and  also  between  these  852  routers 
and  a  single  (duplicate  if  redundant  hardware  is  installed)  front-end  moni¬ 
toring  and  control  (M&C)  server  computer.  Because  this  network  configu¬ 
ration  is  fairly  static,  a  VLAN  should  be  constructed  to  isolate  all  the  852 
routers  and  the  M&C  server  from  the  rest  of  the  IP  network.  However, 
there  will  be  other  client  computers  connected  to  the  front  end  M&C 
server;  these  machines  may  be  on  the  same  VLAN  as  the  852  routers,  or 
they  may  be  on  a  more  general  basewide  IT  VLAN,  in  which  case  the  M&C 
server  would  need  to  exist  on  both  VLANs.  As  an  additional  security  en¬ 
hancement,  VPNs  may  be  used  to  connect  workstation  client  machines  to 
the  M&C  server. 

8.  What  existing  IT  infrastructure  components  beyond  the  network 
itself  will  be  affected? 

In  many  cases,  there  will  be  a  need  for  a  database  server  and/or  a  web 
server.  Purchase,  installation,  operation,  and  maintenance  of  these  ma¬ 
chines  may  be  included  in  an  MOU  between  DOIM  and  the  DPW. 
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9.  What  new  network  infrastructure  components  are  required? 

Buildings  will  need  a  connection  to  the  basewide  IP  backbone.  For  build¬ 
ings  where  this  already  exists,  no  new  components  are  required  beyond  a 
network  drop  and  an  IP  address.  Since  these  devices  require  no  connec¬ 
tivity  beyond  the  M&C  server,  static  private  addresses  are  preferable. 

10.  How  are  the  network  components  secured? 

Ideally,  with  DOIM  permission,  the  CEA-852  routers  will  be  secured  in  the 
same  network  closets  as  the  standard  DOIM  IP  hardware  and  isolated  on  a 
dedicated  VLAN.  The  M&C  server  and  other  client  workstations  will  be  se¬ 
cured  using  whatever  means  the  DOIM  uses  for  standard  office  PCs.  (Note 
that  the  use/capabilities  of  these  computers  could  actually  be  more  re¬ 
stricted  than  for  a  standard  office  computer.  For  example,  these  machines 
should  not  require  access  to  the  Internet  so  it  would  be  possible  to  deny 
them  this  access.  Additional  requirements  may  be  placed  on  these  ma¬ 
chines;  the  only  operational  requirements  are  that  the  M&C  server  be  able 
to  communicate  with  the  BPOCs  and  with  the  workstation  clients.)  No 
specific  security  requirements  are  necessary  for  the  low-level  control 
hardware  inside  the  buildings. 

11.  Can  the  network  components  be  infected  by  a  virus? 

No.  The  network  components  in  the  building  are  low-level  embedded 
processors,  running  very  specific  control  algorithms  on  non-Windows  op¬ 
erating  systems  and  are  not  subject  to  attack  by  viruses,  trojans,  or  worms 
designed  to  attack  general  purpose  PCs  and  network  hardware.  Similarly, 
the  852  routers  are  designed  for  a  specific  task  -  the  routing  of  ANSI  709 
packets.  The  fact  that  they  are  not  IP  routers,  not  general  purpose  com¬ 
puters,  and  are  not  servers  makes  them  extremely  secure  against  outside 
attack. 

12.  Can  network  components  be  hijacked  to  infiltrate  a  network? 

No.  The  low-level  controllers  are  on  a  dedicated  (non-IP)  network  that 
does  not  have  connectivity  outside  the  building.  In  addition,  the  preferred 
configuration  places  the  UMCS  IP  network  on  a  protected  VLAN  and  not 
exposed  to  outside  attack.  Any  possible  attack  against  them  presupposes 
that  the  basewide  IP  network  has  already  been  compromised.  Even  in  the 
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unlikely  event  of  a  successful  attack  against  the  building  control  network, 
the  852  router  does  not  support  standard/common  clients  -  its  usefulness 
as  a  platform  to  attack  the  rest  of  the  network  is  practically  non-existent. 
(Obviously  the  IP  network  -  routers,  switches,  and  cable  drops  -  needs  to 
be  protected  by  standard  DOIM  security  measures.)  Finally,  in  the  event  of 
a  successful  attack  against  the  BAS,  the  compromised  hardware  is  still  on 
an  isolated  VLAN.  The  M&C  server  PC  and  OWSs  will  be  protected  as  any 
standard  PCs  and  DOIM  input  is  required  to  determine  the  best  approach 
to  protecting  these  machines. 

13.  Will  it  require  any  non-standard  ports  be  opened? 

Almost  certainly  not.  The  communication  between  852  routers  and  each 
other  and  the  M&C  server  uses  UDP  and  TCP  ports  1628  and  1629,  which 
are  registered  with  IANA  for  “LonTalk  normal”  and  “LonTalk  urgent.” 
Communication  between  the  M&C  server  and  client  workstations  will  al¬ 
most  certainly  be  via  HTTP  on  port  80;  but  it  is  possible  that  some  vendor 
will  not  use  HTTP  on  port  80  and  will  require  some  non-standard  port. 
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Appendix  C:  DOIM  MOU 

Considerations  for  the  DOIM  MOU: 

•  The  DOIM  POC  is: _ . 

•  The  BAS  Workgroup  POC  is: _ . 

•  DOIM  will  review  any  contract/procurement  package  that  includes  IP 
equipment. 

•  DOIM  has  ownership  of  UMCS  server(s)  while  DPW  owns  the  applica¬ 
tion. 

•  DOM  will  provide  DPW  and  assigned/designated  Contractor(s)  with 
full  access  to  the  Monitoring  and  Control  (M&C)  application  software 
in  order  to  perform  certain  activities  such  as  LNS  database  crea¬ 
tion/merging,  graphic  development,  point  definition,  etc. 

•  DOIM  will  maintain  the  OS  and  perform  daily  backups. 

•  The  Workgroup  /  DPW  will  notify  DOIM  of  any  unscheduled  IP-related 
work. 

•  Server(s)  and  their  location  will  be  pre-approved  by  DOIM. 

•  Un-managed  servers  are  not  permitted. 

•  BPOCs  shall  be  located  in  DOIM  communications  closets  or  other 
DOIM  approved  spaces. 

•  BPOCs  shall  be  tested  for  [ _ ] . 

•  DOIM  will  provide  static  IP  addresses. 

•  Server  and  workstation  Operating  System  software  shall  be  [Windows 
XP], 

•  Office  automation  system  software  shall  be  [MS  Office  Professional 
Version  x  or  later]. 

•  E-mail  software  shall  be  [ _ ]. 

•  No  instant  messaging  (IM)  software  shall  be  permitted  on  any  com¬ 
puter. 

•  M&C  Server  software  will  consist  of:  (for  example)  database  server 

[ _ ],  web  server  [ _ ],  etc. 

•  Server  hardware  and  software  will  be  provided  by  [ _ ] . 

•  Server  maintenance  will  be  provided  by  [ _ ]. 

•  Client  workstation  maintenance  will  be  provided  by  [ _ ] . 

•  DOIM  will  provide  DPW  with  Local  administrator  access/rights  to  the 
Application  programs  (need  to  list  these). 


ERDC/CERL  TR-08-12 


53 


•  Workstation  administrator  requirements  include:  [DOIM  will 
list/describe  System  Administrator  training/certification  requirements 
that  may  be  needed  by  the  DPW  or  DPW-hired-contractor(s)] 

•  etc. 
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Appendix  D:  Installation  Design  Guide  Draft 
Verbiage 

Short  Version 

Digital  controls  shall  be  based  on  LonWorks®  Technology  designed  and 
installed  in  accordance  with  UFGS  23  09  23,  which  is  based  on  ANSI/CEA 
709,  Energy  Information  Administration  (EIA)-852,  and  the  LonMark  In¬ 
teroperability  Guidelines  in  support  of  base-wide  multi -vendor  interop¬ 
erability.  Gateways  (protocol  translators)  shall  be  avoided,  but  may  be  pro¬ 
vided  on  an  exception  basis  only  as  specified  in  UFGS  23  09  23.  BAS 
technologies  that  lead  to  proprietary  sole-source  procurement  for  system 
expansions  are  not  acceptable.  (An  exception  to  UFGS  23  09  23  is  that 
general  purpose  programmable  controllers  [GPPC]  shall  not  be  used.  In¬ 
stead,  only  application  specific  controllers  [ASC]  are  permitted.  Where  an 
application  specific  controller  is  deemed  unsuitable  by  the  contractor  due 
to  the  complexity  of  the  application,  the  contractor  shall  obtain  Contract¬ 
ing  Officer  [or  CO  Representative]  approval  for  use  of  a  programmable 
controller.)  Contractor’s  are  encouraged  to  propose  an  alternate  (less  com¬ 
plex)  control  sequence  that  will  result  in  the  use  of  an  application  specific 
controller  (ASC)  in  lieu  of  a  programmable  controller.  Control  system  in¬ 
stallation  shall  be  coordinated  through  the  DPW  with  the  Fort  [ _ ] 

UMCS  System  Integrator  culminating,  as  specified  in  UFGS  23  09  23,  in 
the  submission  of  an  LNS  database  for  the  project  and  an  LNS  plug-in  for 
each  installed  application  specific  [and  general  purpose  programmable] 
controller/device. 

Detailed  Version:  (Courtesy  of  Fort  Hood,  TX) 

LonWorks®  is  the  overall  open  systems  communication  technology  for 
building  automation  systems.  LonWorks®  is  further  described  by  “Lon¬ 
Mark  International,”  an  industry  organization  established  to  support 
LonWorks®  technology  (http://www.lonmark.orq).  The  term  may  include 
reference  to  any/ all  of  the:  protocol,  network  management,  and  interop¬ 
erability  guidelines  where  the  technology  is  based  on  the  Energy  Informa¬ 
tion  Administration  (ANSI/EIA)  709. lB  protocol  and  employs  interoper- 
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able  devices  along  with  the  capability  to  openly  manage  these  devices  (via 
multiple  vendors)  using  a  network  configuration  (or  service)  tool. 

All  new  and  renovation  control  projects,  where  the  controls  are  to  be  inter¬ 
faced  to  the  Utility  Monitoring  Control  System  (UMCS),  shall  be  coordi¬ 
nated  with  the  Fort  Hood  UMCS  “System  Integrator”  through  the  DPW 
Energy  Branch.  The  UMCS  interface  design  shall  be  in  accordance  with 
Unified  Facility  Guide  Specification  25  10  10  (Utility  Monitoring  Control 
System  -  formerly  UFGS  13801).  In  cases  where  25  10  10  may  not  be  used, 
the  project  design  must  minimally  include  a  “Points  Schedule”  that  lists: 

•  domain/subnet  numbers  (obtained  from  the  UMCS  System  Integrator) 
for  the  installed  controls: 

•  all  points/values  to  be  displayed/monitored  at  the  UMCS 

•  points  that  must  have  override  capability  (such  as  setpoints,  equipment 
on/off  settings) 

•  alarm  conditions/setpoints  (if  applicable)  along  with  names,  e-mail 
addresses,  and/or  pager  numbers  of  individuals  to  be  contacted  (by  the 
UMCS)  in  the  event  of  an  alarm. 

Unified  Facility  Guide  Specification  23  09  23  (Direct  Digital  Control  for 
HVAC  and  other  Local  Building  Systems  -  formerly  UFGS  15951)  ad¬ 
dresses  specifies  system  requirements  for  Direct  Digital  Controls  (DDC) 
using  LonWorks®  that  are  applicable  to  Fort  Hood.  Fundamental  23  09 
23  requirements,  plus  Fort  Hood  specific  requirements  (as  indicated  by 
the  wording  “At  Fort  Hood  ...”)  include: 

1.  The  control  system  shall  be  an  open  implementation  of  LonWorks®  tech¬ 
nology  using  ANSI/EIA  709.1  as  the  communications  protocol  and  using 
LonMark  Standard  Network  Variable  Types  as  defined  in  LonMark  Stan¬ 
dard  Network  Variable  Type  (SNVT)  Master  List  for  communication  over 
the  network; 

2.  All  DDC  hardware  shall  be  connected  to  a  TP/FT-10  ANSI/EIA  709.3  con¬ 
trol  network  and  communicate  over  the  control  network  via  ANSI/EIA 
709.  lB  exclusively. 

3.  LonWorks®  Network  Services  (LNS)  shall  be  used  for  all  network  man¬ 
agement  including  addressing  and  binding  of  network  variables.  A  copy  of 
the  LNS  database  shall  be  submitted  to  the  project  site  as  specified. 

4.  The  hardware  shall  perform  the  control  sequences  as  specified  and  shown 
to  provide  control  of  the  equipment  as  specified  and  shown. 
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5.  LonMark  certified  control  hardware  (devices)  shall  be  used  when  a  device 
that  meets  the  control  sequence  is  available.  Certified  devices  are  listed  at 
http://www.lonmark.org/products/.  At  Fort  Hood,  if  minor  deviations  from  the 
specified  control  sequence  would  permit  the  use  of  a  Certified  device 
(when  one  is  otherwise  not  available),  the  contractor  is  encouraged  to 
submit  the  Certified  device  along  with  a  description  of  the  deviation(s). 
Non-certified  devices  are  permissible  as  long  as  they  otherwise  adhere  to 
the  specified  LonWorks®  requirements. 

6.  At  Fort  Hood,  application  specific  control  (ASC)  hardware  is  preferred 
over  programmable  controllers.  If  minor  deviations  from  the  specified 
control  sequence  would  permit  use  of  an  ASC  (when  a  programmable  con¬ 
troller  would  otherwise  be  required),  the  contractor  is  encouraged  to  sub¬ 
mit  the  ASC  along  with  a  description  of  the  deviation(s). 

7.  LNS  plug-ins  shall  be  provided  with  all  control  hardware.  Devices  without 
LNS  plug-ins  shall  be  used  on  an  exception  basis  only  and  require  Gov¬ 
ernment  approval.  A  partial  list  of  control  hardware  with  LNS  plug-ins  is 
available  through  URL: 

http://www.echelon.com/products/networktools/pluqin/default.asp 

8.  At  Fort  Hood,  packaged  HVAC  units/equipment  shall  include  factory  in¬ 
stalled  LonWorks®  control  hardware  when/where  this  control  option  is 
available.  Fort  Hood’s  prefers  that  the  contractor  select  packaged  HVAC 
units  that  provide  this  control  option. 

9.  Control  sequence  logic  shall  reside  in  DDC  hardware  in  the  building.  The 
building  control  network  shall  not  be  dependent  on  connection  to  a  Utility 
Monitoring  and  Control  System  (UMCS)  for  performance  of  control  se¬ 
quences  in  this  specification.  The  hardware  shall,  to  the  greatest  extent 
practical,  perform  the  sequences  without  reliance  on  the  building  network. 

10.  The  hardware  shall  be  installed  such  that  individual  control  equipment  can 
be  replaced  by  similar  control  equipment  from  other  equipment  manufac¬ 
tures  with  no  loss  of  system  functionality. 

11.  All  necessary  documentation,  configuration  information,  configuration 
tools,  programs,  drivers,  and  other  software  shall  be  licensed  to  and  oth¬ 
erwise  remain  with  the  Government  or  their  agents  are  able  to  perform  re¬ 
pair,  replacement,  upgrades,  and  expansions  of  the  system  without  subse¬ 
quent  or  future  dependence  on  the  Contractor, 

12.  The  Contractor  shall  provide  sufficient  documentation  and  data,  including 
rights  to  documentation  and  data,  such  that  the  Government  or  their 
agents  can  execute  work  to  perform  repair,  replacement,  upgrades,  and 
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expansions  of  the  system  without  subsequent  or  future  dependence  on  the 
Contractor. 

13.  Hardware  shall  be  installed  and  configured  such  that  the  government  or 
their  agents  are  able  to  perform  repair,  replacement,  and  upgrades  of  indi¬ 
vidual  hardware  without  further  interaction  with  the  Contractor. 

14.  Control  hardware  shall  be  installed  and  configured  to  provide  all  input  and 
output  Standard  Network  Variables  (SNVTs)  as  shown  and  as  needed  to 
meet  the  requirements  of  this  specification. 

15.  All  DDC  devices  installed  under  this  specification  shall  communicate  via 
ETA  709. lB.  The  control  system  shall  be  installed  such  that  a  SNVT  output 
from  any  node  on  the  network  can  be  bound  to  any  other  node  in  the  do¬ 
main. 
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Appendix  E:  UMCS  System  Administrator, 
Tech  Support  Rep,  and  System  Integrator 
SOW 


Appendix  E 

<Post  Name> 

UMCS  System  Administrator^  Technical  Support  Representative, ][  and 

System  Integrator] 

Statement  of  Work 


Specifier  Note: 

1 .  This  SOW  can  be  used  to  obtain  “long-term”  support  of  a  UMCS  and/or 
building  control  systems.  Several  tasks  are  included  and  the  SOW  must 
be  edited  to  remove  any  tasks  that  are  not  desired.  In  general,  this  SOW 
can  provide: 

2.  A  technical  service  representative  (TSR)  embedded  in  the  maintenance 
shop  to  assist  with  building  control  systems 

3.  A  UMCS  System  Administrator  to  develop  and  maintain  procedures  for 
UMCS  operation  and  the  integration  of  building  systems  into  the  UMCS. 
This  System  Administrator  may  also  perform  the  “day-to-day”  tasks  re¬ 
quired  to  maintain  the  UMCS 

4.  A  System  Integrator  to  perform  integration  of  building  DDC  systems  into 
the  UMCS.  In  this  case  this  SOW  must  be  editing  to  include  the  require¬ 
ments  of  the  UMCS  DDC  Integration  SOW.. 

5.  Some  of  the  required  entries  to  edit  this  SOW  are  in  Word  fields.  To  up¬ 
date  these  fields,  click  in  the  body  of  the  document  press  Ctrl-A  (to  select 
all)  then  press  F9  and  you  will  be  prompted  for  the  correct  information. 

6.  Entries  in  fields  are  in  “<  >”  brackets  and  you  will  be  prompted  for  them 
when  you  update  fields.  Entries  requiring  manual  editing  are  in  “[  ]”  brack¬ 
ets. 

7.  These  instructions  and  all  specifier  notes  are  in  single  cell  tables  -  just  de¬ 
lete  the  table  when  done  editing  this  document. 

8.  A  standalone  version  of  this  SOW  in  Microsoft  Word  format  is  available  at 
the  ERDC-CERL  Building  Automation  Systems  Team  website  at 

https://eko.usace.armv.mil/fa/bas/ 
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1.  OBJECTIVE 

The  Contactor  shall  provide  technical  support  to  <Post  Name>’s  <UMCS  Manu¬ 
factured  <UMCS  Model>  Utility  Monitoring  and  Control  System  (UMCS).  The 
Contractor  shall: 


Specifier  Note:  The  bulleted  list  includes  a  selection  of  tasks  that  can  be 
covered  by  this  SOW.  Include  the  bullets  and  corresponding  paragraphs  for 
items  you  want  as  part  of  this  SOW  and  remove  the  others. 


•  develop  and  document  a  System  Integration  Methodology 

•  develop  and  document  a  System  Operation  Methodology 

•  manage  and  operate  the  UMCS  according  to  the  Operation  Methodology 

•  perform  integration  of  building  DDC  systems  according  to  the  System  Inte¬ 
gration  Methodology 

•  provide  OMD-embedded  maintenance  support 

2.  REQUIREMENTS 

<Post  Name>  currently  has  a  <UMCS  Manufactured  <UMCS  Model>  Utility 
Monitoring  and  Control  System  installed  in  accordance  with  the  requirements  of 
UFGS  25  10  10.  Unless  otherwise  indicated  all  requirements  of  this  Statement  of 
Work  pertain  to  this  UMCS.  All  work  performed  by  the  contractor  shall  ensure 
that  the  system  is  an  Open,  LNS-Based  Flat  LON  system  in  accordance  with 
UFGS  25  10  10.  In  cases  where  UFGS  25  10  10  allows  options  the  Contractor 
shall  coordinate  these  options  with  <Post  Name>. 

2.1.  US  Citizenship  Requirements 

Contractor  must  insure  that  all  contractor  personnel  who  will  work  on  <Post 
Name>  or  have  access  to  information  that  describes  the  <Post  Name>  Utility 
Monitoring  and  Control  System  (UMCS)  must  be  United  States  citizens.  Con¬ 
tractor  will  be  responsible  for  insuring  that  all  subcontractor  personnel,  at  any 
tier,  having  access  to  information  about  the  <Post  Name>  UMCS  are  United 
States  citizens.  The  contractor  is  expected  to  secure  all  drawings  or  other 
descriptive  information  concerning  the  current  <Post  Name>  UMCS  so  ac¬ 
cess  is  granted  only  to  those  who  need  the  information  to  perform  work  under 
this  contract. 

2.2.  Embedded  Maintenance  Support 

Specifier  Note:  Indicate  the  name  of  the  maintenance  shop  (For  example 
for  Fort  Bragg  this  is  Operations  Maintenance  Division  [OMD]) 

The  bracketed  number  of  hours  is  for  1  year.  Adjust  as  needed  for 
more/less  support. 


The  contractor  shall  provide  a  technical  service  representative  (TSR)  embed¬ 
ded  in  the  Maintenance  Shop>.  The  embedded  TSR  shall  maintain  a 
physical  presence  in  the  shops  according  to  a  mutually  agreed  upon  work 
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schedule  for  a  total  of  [1800  hours]  under  this  contract.  The  Contractor  shall 
assign  specific  staff  to  perform  the  TSR  services  and  shall  not  rotate  staff  in 
and  out  of  the  TSR  role  where  the  intent  of  this  requirement  is  to  maintain 
consistency.  TSRs  are  not  required  nor  expected  to  participate  in  mainte¬ 
nance  support  activities  outside  of  or  beyond  the  scope  of  this  contract. 

The  TSR  shall: 

2.2.1.  Provide  maintenance  support  services  for  both  new  and  existing 
control  systems  equipment  and  hardware.  Intimate  familiarity  with 
LonWorks  DDC  Systems  and  with  the  <UMCS  Manufacturer’s 
<UMCS  Model>.  is  required  along  with  a  working  knowledge  of 
other  equipment  and  hardware  such  as  pneumatics,  analog  elec¬ 
tronic  and  single-loop  digital  control.  The  support  requirements 
apply  to  all  control  systems  regardless  of  whether  or  not  the  sys¬ 
tem  is  connected  to  the  UMCS. 

2.2.2.  Assist  Maintenance  Shop>  staff  with  control  system  problem 
identification,  diagnosis,  maintenance,  repair,  installation,  and 
commissioning.  This  includes  the  generation  of  service  orders  ac¬ 
cording  to  Maintenance  Shop>  procedures.  TSR  shall  pay  par¬ 
ticular  attention  to  systems  and  equipment  that  is  under  warranty 
where  the  intent  is  to  identify  problems  prior  to  warranty  expiration 
and  have  repairs  performed  under  warranty  by  the  installing  con¬ 
tractor. 

2.2.3.  Assist  with  in-house  renovation  projects  including  the  development 
of  project  requirements,  specifications,  drawings,  scope  of  work, 
cost  estimates,  bill  of  materials,  installation,  and  inspection. 

2.2.4.  Provide  scheduled  and  on-the-job  UMCS  and  DDC  training  to 
Maintenance  Shop>  staff.  Scheduled  training  shall  be  class¬ 
room  style  at  mutually  agreed  upon  periodic  intervals.  The  dura¬ 
tion,  scheduling,  and  content  of  scheduled  training  shall  be  mutu¬ 
ally  agreed  upon  by  the  TSR  and  Maintenance  Shop> 
maintenance  staff. 

2.2.5.  Obtain  and  maintain  a  cell  phone  service  and  provide  cell  phone 
number  to  Maintenance  Shop>  staff.  TSR  shall  carry  the  phone 
at  all  times  during  the  agreed  upon  work  schedule  and  shall  use 
this  phone  for  communicating  with  Maintenance  Shop>  staff. 

2.2.6.  Provide  and  be  responsible  for  their  own  transportation  vehicle,  di¬ 
agnostic  equipment,  and  hand  tools.  Contractor  owned  vehicles 
shall  meet  the  “Contractor  Owned  Vehicle  Requirements”  in  Ex¬ 
hibit  A. 

2.2.7.  Provide  monthly  activity  summary  reports.  Reports  should  be  brief 
summaries  of  activities  performed  for  the  month.  These  reports 
shall  be  organized  as  follows: 

a.  List  of  DDC  Systems  supported  (as  described  in  2.2.1.  ) 
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b.  Summary  of  Maintenance  Shop>  staff  assistance  provided 
(as  described  in  2.2.1 . ): 

i.  problems  identified  for  warranted  systems 

ii.  commissioning  support  provided 

iii.  other  support  activities 

c.  Summary  of  assistance  provides  to  in-house  renovation  pro¬ 
jects  (as  described  in  2.2.2.  ) 

d.  Summary  of  training  provided  (as  described  in  2.2.3. )  including 
dates,  times,  attendance  and  content  of  scheduled  and  on-the- 
job  training  sessions. 

2.3.  UMCS  Operation  and  Management 

2.3.1.  UMCS  Operation  Methodology 

The  Contractor  shall  develop  and  document  a  UMCS  Operation  Method¬ 
ology.  As  part  of  this  the  Contractor  shall  coordinate  with  DPW  and 
Maintenance  Shop>  staff  in  the  identification  and  development  of  proc¬ 
esses  for  operation  of  the  UMCS  and  shall  implement  mutually  agreed 
upon  processes.  The  processes  shall  take  into  consideration  the  current 
and  future  anticipated  needs  and  uses  of  the  UMCS.  These  processes  in¬ 
clude,  but  are  not  limited  to: 


Specifier  Note:  Include  a  list  of  computers  that  must  be  able  to  access  the 
UMCS. 


a.  DPW  and  Maintenance  Shop>  access.  Fort  Bragg  needs 
access  to  the  system  according  to  defined  procedures  and  lo¬ 
gistics  including  but  not  limited  to  password  levels/limits  and 
access  to  and  training  on  tools.  Coordinate  with  the  installation 
Directorate  of  Information  Management  (DOIM)  to  ensure  that 
the  following  computers  can  access  the  UMCS:  [LIST  OF 
COMPUTERS], 

b.  DPW  Tools.  Describe  a  methodology  for  Operation  Mainte¬ 
nance  Division  (OMD)  access  to  and  use  of  the  UMCS  and  re¬ 
lated  tools  such  as  laptops  including  OMD  responsibilities  and 
obligations. 

c.  Service  Calls.  Define  the  process  whereby  the  UMCS  Contrac¬ 
tor  responds  to  requests  for  information  and  diagnostic  actions 
to  be  taken  by  the  UMCS  operator  in  response  to  calls  from 
maintenance  staff  who  are  troubleshooting  DDC  systems  that 
are  connected  to  the  UMCS. 

d.  Alarms.  Define  the  process  whereby  alarms  received  by  the 
UMCS  from  DDC  systems  connected  to  the  UMCS  are  se¬ 
lected,  setup,  monitored,  routed,  and  managed.  This  includes 
the  generation  of  work  orders  based  on  received  alarms. 
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e.  Energy  Savings.  Define  the  process  for  reducing  energy  con¬ 
sumption,  tracking  energy  savings,  data  archiving,  and  trend¬ 
ing  towards  meeting  LEED  goals  and  standards  along  with  the 
creation  and  management  of  equipment  usage  and  perform¬ 
ance  reports. 

f.  UMCS  Training.  Identify  and  define  training  needs  and  require¬ 

ments  for  DPW  staff.  Note:  The  contractor  shall  provide  UMCS 
training  as  specified  in  UFGS  25  10  10. 

g.  Installation  Design  Guide  (IDG).  Installation  Design  Guide 
(IDG).  The  Contractor  shall  provide  verbiage  for  suggested 
changes  to  Fort  Bragg  IDG  in  support  of  an  open  basewide 
UMCS  and  in  support  of  its  successful  management,  opera¬ 
tion,  and  maintenance. 

2.3.2.  UMCS  Operation  and  Management 

The  Contractor  shall  manage  the  UMCS  in  a  manner  consistent  with  the 
requirements  and  intent  of  UFGS  25  10  10,  UFGS  23  09  23  and  the  fol¬ 
lowing  requirements: 

a.  Systems  Integration  Log.  The  Contractor  shall  develop  and 
maintain  an  up-to-date  log  consisting  of: 

i.  Documentation  drawings  and  submittals  specified  in 
UMCS  UFGS  25  10  10  for  the  UMCS. 

ii.  Documentation  drawings  and  submittals  specified  in  DDC 
UFGS  23  09  23  for  DDC  systems  connected  to  the  UMCS 
or  those  for  which  future  connection  is  anticipated. 

iii.  Related  documentation  as  specified  in  this  SOW. 

iv.  System  Administrator  and  Information  Assurance  docu¬ 
ments,  records,  and  certification  data. 

v.  Maintenance  and  repair  records. 

vi.  Meeting  minutes 

These  items  are  further  described  below. 

b.  Documentation.  The  Contractor  shall  compile,  manage,  store, 
and  maintain  UMCS  and  related  DDC  system  documentation. 
As  part  of  this  the  Contractor  shall  assist  the  DPW  to  identify, 
locate,  and  assemble  existing  UMCS  and  DDC  materials  that 
will  facilitate  the  implementation  of  the  UMCS  as  a  basewide 
system  such  DDC  system  drawings,  LNS  databases,  Points 
Schedules,  technical  references,  etc. 

c.  System  Administrator.  The  Contractor  shall  serve  as  a  system 
administrator  for  the  UMCS  (on  the  Army  enterprise  network) 
and  UMCS  computers  and  shall  obtain  all  necessary  training 
and  certifications  and  otherwise  meet  Information  Assurance 
requirements  as  described  in  Exhibit  A  for  the  Contractor  staff 
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and  for  the  UMCS  as  needed  to  perform  system  administrator 
duties  for  the  UMCS. 

d.  Maintenance  and  Repair.  The  Contractor  shall  maintain  the 
UMCS  including: 

i.  Maintenance  and  repair  of  hardware 

ii.  Maintain  all  UMCS  related  software  including  Monitoring 
and  Control  software  and  Network  Configuration  Tool  soft¬ 
ware  including  up-to-date  patches,  fixes,  upgrades 

iii.  Perform  database  backups 

iv.  Maintain  user  accounts  and  permissions 

v.  Update  UMCS  with  applicable  data  as  needed  from  other 
computers  systems  such  as  automatic  meter  reading,  elec¬ 
trical  distribution  SCADA,  etc. 

vi.  Provide  data  to  other  computer  systems  or  personnel  as 
needed 

e.  DDC  Contractor  Coordination.  The  Contractor  shall  work  with 
DDC  contractors  to  clarify  open  system  and  integration  re¬ 
quirements  and  demonstrate  the  UMCS. 

f.  Meetings  and  Reviews.  The  Contractor  shall  attend  the  monthly 

<Post  Meeting>.  UMCS  Workgroup  meetings.  The  Contractor 
shall  attend  design  and  planning  charrettes  and  shall  review 
UMCS  and  DDC-related  designs  for  Military  Construction  and 
other  funded  projects.  The  Contractor  shall  review  DDC  sys¬ 
tem  submittals  from  third  party  DDC  system  contractors  to  de¬ 
termine  if  the  DDC  system  meets  the  requirements  of  the  Sys¬ 
tem  Integration  Methodology.  The  Contractor  may  provide 
recommendations  to  the  government  but  will  not  be  permitted 
nor  be  responsible  for  accepting  or  rejecting  other  Contractors 
work  or  submittals.  The  Contractor  shall  provide  minutes  for  all 
meetings  held  with  the  government. 

2.4.  System  Integration 

2.4.1.  System  Integration  Methodology.  The  Contractor  shall  develop  a 
System  Integration  Methodology  in  accordance  with  the  open  sys¬ 
tem  requirements  in  this  SOW,  UMCS  UFGS  25  10  10,  and  the 
applicable  integration-related  requirements  of  DDC  UFGS  23  09 
23.  The  methodology  shall  describe  the  technical  approach  for  ac¬ 
complishing  the  integration  of  DDC  systems  installed  in  accor¬ 
dance  with  DDC  UFGS  23  09  23  including  those  installed  by  third- 
party  contractors.  The  description  shall  include  all  elements  con¬ 
tained  in  this  SOW  including  but  not  limited  to: 

a.  Government  Coordination.  Describe  the  coordination  proce¬ 
dures  including  that  with,  at  a  minimum,  the  following  Govern¬ 
ment  personnel: 
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•  DPW,  Energy  Manager:  name,  phone,  e-mail. 
Role/responsibility. 

•  DPW,  Chief  of  O&M:  name,  phone,  e-mail. 
Role/Responsibility. 

•  DPW,  Shop  Foremen:  name,  phone,  e-mail. 
Role/Responsibility. 

•  DPW,  Shop  Work  Leaders:  name,  phone,  e-mail. 
Role/Responsibility. 

•  DOIM:  names,  phone,  e-mail.  Role/Responsibility. 

•  District  Office  Engineer:  names,  phone,  e-mail. 
Role/Responsibility. 

•  Area  Office  Engineer:  names,  phone,  e-mail. 
Role/Responsibility. 

b.  UMCS  Connectivity.  Describe  the  procedure  for  providing  the 
BPOC  and  obtaining  the  IP  connection.  For  example,  will  the 
UMCS  Contractor  install  the  ANSI/EIA  709.1  to  IP  ANSI/EIA 
852  router  to  connect  the  building  level  control  system  to  the 
base-wide  IP  network?  Alternatively,  the  SIM  may  call  for  the 
UFGS  23  09  23  Contractor  to  provide  the  router  as  part  of  the 
building  level  contract  --  the  actual  approach  must  be  defined 
in  the  SIM. 

c.  LNS  Database.  Describe  the  procedure  for  managing  the 
UMCS  LNS  database(s)  including  the  approach  for  integration 
of  UFGS  23  09  23  systems.  For  example,  should  building  con¬ 
tractors  work  directly  from  the  basewide  LNS  database?  Will 
building  databases  be  merged  to  create  a  single  basewide  da¬ 
tabase  or  maintained  as  separate  databases?  What  guidelines 
will  be  used  to  determine  when  databases  are  or  are  not 
merged?  Will  DSN  addresses  need  to  be  reassigned?  Will  a 
separate  database  be  assigned  to  each  third-party  contractor? 

d.  UMCS  Integration  Checklist.  Develop  a  checklist  of  activities 
and  describe  information  to  be  provided  by  the  UMCS  Con¬ 
tractor  to  third-party  DDC  UFGS  23  09  23  contractors  that  is 
needed  by  these  third-party  contractors  in  order  to  perform 
successful  integration  with  the  UMCS,  such  as  domain  names 
and  addressing.  List  and  describe  submittals  and  technical  in¬ 
formation  needed  from  third  party  contractors  in  order  to  ac¬ 
complish  integration  of  third-party  UFGS  23  09  23  systems. 

e.  DDC  Integration  Checklist.  Develop  a  checklist  of  activities  and 
describe  information  to  be  provided  by  the  DDC  UFGS  23  09 
23  Contractor  to  the  UMCS  Contractor  that  is  needed  by  the 
UMCS  Contractor  to  perform  successful  integration  with  the 
UMCS.  This  might  consist  of:  LNS  database  handling  and 
submission,  LNS  Plug-ins  submittals,  XIF  and  other  resource 
file  submittals,  software  licenses  and  LNS  credits,  program¬ 
ming  software  and  source  code  submittals,  verifying  required 
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SNVTs  per  Points  Schedule  drawing,  Verify/add  bindings  as 
needed,  verifying  override  points  defined/available,  Points 
Schedule  drawing  submittal,  Riser  Diagram  drawing  submittal. 
Potential/expected  recommissioning  of  field  devices  (obtaining 
field  data,  not  sending  it). 

f.  M&C  Software  Configuration.  Provide  step-by-step  description 

for  programming,  configuring  and  otherwise  setting  up  hard¬ 
ware  and  software  to  accomplish  Monitoring  and  Control  soft¬ 
ware  functionality  specified  in  UFGS  25  10  10  so  as  to  accom¬ 
plish  integration  of  third-party  UFGS  23  09  23  systems.  This 
shall  include  obtaining  or  development  of  a  Points  Schedule 
drawing  for  the  system  to  be  integrated. 

g.  Acceptance  and  startup  procedures.  Describe  any  inspections 
or  testing  to  be  performed  to  verify  that  the  interface  between 
the  UMCS  and  the  third-party  building-level  system  can  be  ac¬ 
complished. 

2.4.2.  UMCS  DDC  Integration.  The  contractor  shall  integrate  LNS-based 
LonWorks  DDC  systems  into  the  UMCS.  System  integration  shall 
be  in  accordance  with  the  following: 

Specifier  Note:  If  you  keep  this  UMCS  DDC  System  Integration  option, 
copy  paragraphs  3,  4  and  5  from  the  ‘UMCS  DDC  Integration  SOW’  into  this 
SOW  so  as  to  specify/define  the  integration  requirements. 


Also,  complete  the  bracketed  option  defining  the  scope  of  the  integration 
services  that  the  contractor  shall  provide.  This  can  be  done  by  listing  build¬ 
ings  or  systems,  by  number  of  graphic  pages  and  points  or  by  specifying  a 
number  of  hours  (level  of  effort).  Use  caution  when  specifying  as  a  number 
of  hours  since  there  is  no  easy  metric  to  measure  if  the  contractor  is  “drag¬ 
ging  his  feet”. 


The  contractor  shall  provide  integration  services  for  [ _ ]. 

3.  DELIVERABLES 

Specifier  Note:  The  current  (bracketed)  due  dates  for  the  deliverables  as¬ 
sumes  this  is  a  1-year  contract.  Edit  the  due  date  for  all  deliverables  to  re¬ 
flect  actual  requirements. 


Unless  otherwise  noted  below,  each  of  the  below  submittals  shall  be  in  editable 
electronic  format  on  CD-ROM  (no  PDFs  unless  otherwise  approved)  and  in  hard¬ 
copy  format. 
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3.1.  Embedded  Technical  Service  Representative  (TSR)  Activity  Sum¬ 
maries 

[Monthly  activity  summary  report  for  each  month  due  on  the  5th  day  of  the 
following  month  except  that  the  summary  report  for  the  last  month  of  this 
contract  is  due  on  the  last  day  of  the  performance  period.] 

3.2.  UMCS  Operation  Methodology 

Initial  submittal  [3  months  after  award] 

Final  submittal  [2  months  prior  to  contract  completion] 

3.3.  System  Integration  Methodology 

Initial  submittal  [3  months  after  award] 

Final  submittal  [2  months  prior  to  contract  completion] 

3.4.  Systems  Integration  Log 

Initial  submittal  [6  months  after  award] 

Final  submittal  [2  months  prior  to  contract  completion] 

3.5.  Meeting  Minutes 

Meeting  minutes  shall  be  delivered  via  email  within  1  week  after  each 
meeting. 

4.  PERIOD  OF  PERFORMANCE 

Specifier  Note:  Specify  the  duration  for  the  project.  If  you  specified  a  num¬ 
ber  of  hours  for  a  TSR  or  for  DDC  UMCS  Integration  make  the  completion  of 
the  project  allows  enough  time  for  those  hours. 

Completion  of  this  project  will  be  [ _ ]. 

5.  DISTRIBUTION 

Specifier  Note:  Specify  distribution  for  all  deliverables. 

Distribution  for  all  deliverables  of  this  project  will  be  [ _ ] 


ERDC/CERL  TR-08-12 


68 


Exhibit  A:  Network  Access  Requirements 


Specifier  Note:  The  System  Administrator  will  need  to  work  on  a  Govern¬ 
ment  computer  system  to  perform  the  requirements  of  this  SOW.  Coordi¬ 
nate  with  the  installation  DOIM  to  identify  any  requirements  that  the  contrac¬ 
tor  must  meet  in  order  to  access  Government  networks  and  computers  and 
include  them  here.  The  below  text  is  from  a  SOW  generated  by  Fort  Bragg 
and  is  included  as  an  example  only. 

Example  Network  Access  Requirements  For  U.S.  Government  Contracts 

1.  Information  Assurance  (IA).  Contractor  personnel  requiring  access  to  U.S. 
Government  Information  Systems  to  fulfill  their  duties  shall  possess  the  re¬ 
quired  favorable  security  investigation,  security  clearance,  formal  access 
approval,  and  need-to-know  prior  to  being  granted  access  to  any  Govern¬ 
ment  computer  or  computer  network. 

2.  IT-I  Level  of  Security  Access  is  required  for  Contractor  personnel  in  IA 
Position  working  with  infrastructure  devices,  IDSs,  routers,  System  Admini¬ 
stration  or  Network  Administration,  with  privileged-level  access  to  control, 
manage,  or  configure  Information  Assurance  tools  or  devices,  individual  in¬ 
formation  systems,  networks,  and  enclaves.  At  a  minimum,  such  Contractor 
Personnel  shall  require  a  favorably  completed  NAC,  initiation  of  SSBI,  com¬ 
pletion  of  SF85P,  SF86,  and  Supplemental  Guestionnaire. 

3.  IT-II  Level  of  Security  Access  is  required  for  Contractor  personnel  in  IA 
positions  requiring  the  work  with  operating  systems  administration  of  com¬ 
mon  applications  or  enclaves,  or  back-up  operators,  with  limited  privileged 
level  access  to  control,  manage,  or  configure  information  systems  or  de¬ 
vices.  At  a  minimum,  such  contractor  personnel  shall  require  a  favorable 
review  of  local  personnel,  base/military,  medical  and  other  security  records 
as  appropriate,  initiation  of  a  NACLC,  and  completion  of  the  SF85P  or  SF86 
and  Supplemental  Guestionnaire. 

4.  IT-Ill  Level  of  Security  Access  is  required  for  Contractor  personnel  in  po¬ 
sitions  as  normal  users,  power  user  on  individual  systems  for  configuration 
with  non-privileged  level  of  access  to  information  systems  and  devices.  At  a 
minimum,  such  contractor  personnel  shall  require  a  favorable  review  of  local 
personnel,  base/military,  medical  and  other  security  records  as  appropriate, 
initiation  of  a  NAC,  and  completion  of  the  SF85P  and  Supplemental  Gues¬ 
tionnaire. 

5.  Contractor  personnel  shall  not  be  granted  access  to  any  Government 
computer  systems  or  networks  until  proof  of  compliance  to  the  Information 
Assurance  (IA)  clearance  requirements. 

6.  Once  Contract  personnel  have  complied  with  the  Information  Assurance 
requirements  as  reflected  above,  they  will  be  granted  the  appropriate  Infor¬ 
mation  Technology  level  of  security  access. 
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7.  Contractor  Personnel  shall  personally  pick-up  and  sign  for  Government 
network  user  identification  and  password  at  the  1 1 1 2th  Signal  Battalion  In¬ 
formation  Assurance  Office. 

8.  Contractor  Employee(s)  shall  be  solely  responsible  for  the  safeguarding 
of  user  passwords,  and  shall  immediately  report  any  suspected  compromise 
or  loss  of  password  to  the  1 1 1 2th  U.S.  Army  Signal  Battalion  Information  As¬ 
surance  Office,  Building  1-1554. 

9  The  Contractor  is  responsible  for  notifying  the  Contract  Officer  Represen¬ 
tative  (COR)  and  also  the  1 1 12th  U.S.  Army  Signal  Battalion  Information  As¬ 
surance  Office  of  any  changes  to  their  or  their  personnel’  status. 
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Appendix  F:  UMCS  DDC  Integration  SOW 

<Post  Name>  UMCS  DDC  Integration 
Statement  of  Work 

[project  number  /  identifier] 

[date] 


Specifier  Note: 

1  This  SOW  can  be  used  to  obtain  system  integration  services  to  inte¬ 
grate  an  LNS-based  LonWorks  building  control  system  into  an  LNS- 
based  LonWorks  UMCS. 

2  For  MILCON  projects  this  SOW  can  be  used  by  having  the  district 
MIPR  projects  funds  to  a  contracting  entity  to  award  the  integration  ser¬ 
vices.  For  example,  at  Fort  Bragg: 

a.  Savannah  District  (SAS)  completes  this  document  (bracketed  op¬ 
tions)  and  sends  it  along  with  the  noted  attachments  to  Huntsville 
(HNC). 

b.  HNC  obtains  integration  pricing  based  on  this  SOW. 

c.  SAS  MIPRs  the  required  funds  to  HNC  to  award  the  contract/task 
order. 

3  Some  of  the  required  entries  to  edit  this  SOW  are  in  Word  fields.  To 
update  these  fields,  click  in  the  body  of  the  document  press  Ctrl-A  (to 
select  all)  then  press  F9  and  you  will  be  prompted  for  the  correct  infor¬ 
mation. 

4  Entries  in  fields  are  in  <>  brackets  and  you  will  be  prompted  for  them 
when  you  update  fields.  Entries  requiring  manual  editing  are  in  [] 
brackets. 

5  These  instructions  and  all  specifier  notes  are  in  single  cell  tables  -  just 
delete  the  table  when  done  editing  this  document. 
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1 .0  SYNOPSIS:  The  Contractor  shall  provide  the  materials  and  labor  required  to 
integrate  direct  digital  control  (DDC)  systems  into  the  <Post  Name>  base¬ 
wide  <UMCS  Manufactured  <UMCS  Model>  Utility  Monitoring  and  Control 
System  (UMCS). 

2.0  PRICE  PROPOSAL:  The  Contractor  shall  provide  a  firm  fixed  price  proposal 
for  the  integration  of  the  Direct  Digital  Control  (DDC)  systems  specified  below 
into  the  <Post  Name>  Utility  Monitoring  Control  System  (UMCS). 


Specifier  note:  System  integration  should  be  done  in  accordance  with  the 
System  Integration  Methodology  (SIM)  if  the  installation  has  one.  Include 
the  bracketed  text  if  the  installation  has  a  SIM  and  remove  it  otherwise. 


3.0  SPECIFIC  WORK  TO  BE  ACCOMPLISHED:  The  Contractor  shall  provide 
materials  and  labor  required  to  integrate  LNS-based  LonWorks  Direct  Digital 
control  (DDC)  systems  specified  into  the  <Post  Name>  Utility  Monitoring 
Control  System  (UMCS).  All  work  shall  be  in  accordance  with  [the  approved 
<Post  Name>  System  Integration  Methodology,]  and  Unified  Facilities  Guide 
Specification  (UFGS)  25  10  10  and  this  SOW.  All  work  performed  by  the  con¬ 
tractor  shall  ensure  that  the  system  is  and  remains  an  Open,  LNS-Based  Flat 
LON  system  in  accordance  with  UFGS  25  10  10.  In  cases  where  UFGS  25 
10  10  allows  options  the  Contractor  shall  coordinate  these  options  with  <Post 
Name>. 

3.1  The  contractor  shall  integrate  the  following  building  DDC  systems: 


Specifier  note:  Identify  all  systems  to  be  integrated.  If  BPOC  Locations  and  IP 
Addresses  are  going  to  be  listed  in  this  SOW  (as  opposed  to  on  a  drawing  or  re¬ 
quiring  coordination  -  see  next  specifier  note)  you  may  want  to  put  a  table  here 
showing  this  information  as  well.  For  example: 


System 

BPOC  Location 

BPOC  IP  Address 

Bldg  52  West  Wing 

Bldg  52,  room  215 

192.168.2.101 

Bldg  52  East  Wing 

Bldg  52,  room  215 

192.168.2.105 

Bldg  62  AHU  1 

Bldg  62,  room  410 

192.168.2.108 

3.1.1  [list  the  DDC  systems  and/or  buildings] 

3.2  For  each  DDC  system  the  contractor  shall  perform  all  tasks  required 
to  fully  integrate  the  system  into  the  UMCS  including  but  not  limited  to: 

3.2.1  Install  an  ANSI/CEA  709.1  to  ANSI/CEA  852  router  Build¬ 
ing  Point  of  Connection  (BPOC)  to  connect  the  building 
DDC  system  to  the  UMCS  IP  backbone. 
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Specifier  note: 

Provide  BPOC  locations  by  one  of  the  following: 

•  Include  a  drawing/document  with  these  locations  with  the  SOW 

•  List  the  locations  (building/room  number)  here. 

•  Refer  to  the  table  (see  previous  specifier  note)  where  they  are  listed. 

Similarly,  provide  IP  addresses  for  the  BPOC.  Note  that  the  IP  addresses  may 
not  be  known  pre-award  in  which  case  choose  either  to  provide  them  to  the  con¬ 
tractor  post-award  or  require  that  the  contractor  obtain  them  from  DOIM.  If  re¬ 
quiring  the  contractor  to  obtain  them  from  DOIM  provide  a  DOIM  point  of  contact. 

Note  that  this  SOW  assumes  that  the  BPOC  location  is  the  location  of  the  IP  drop 
provided  by  DOIM. 


3. 2. 1.1  BPOC  locations  are  [shown  in  the  Government  fur¬ 
nished  documents]  [ _ ]. 

3. 2. 1.2  BPOC  IP  addresses  [are  shown  in  the  Govern¬ 

ment  furnished  documents][will  be  provided  after 
contract  award][shall  be  obtained  from  <Post 
Name>  DOIM.  DOIMPOCis[ _ ]][ _ ] 

3.2.2  Incorporate  each  DDC  system  LNS  database  into  the 
UMCS  database: 


Specifier  note:  Include  bracketed  text  referring  to  the  system  integration 
methodology  if  the  installation  has  one,  otherwise  remove  the  bracketed 
text. 


3.2.2. 1  Merge  the  building  database  into  the  UMCS  da¬ 
tabase  or  establish  a  new  LNS  database  at  the 
UMCS  as  required  to  maintain  UMCS  perform¬ 
ance  [and  in  accordance  with  the  System  Integra¬ 
tion  Methodology], 

3. 2. 2. 2  Install  and  update  LNS  plug-ins  in  the  <Post 
Name>  LNS  network  configuration  tool. 

3. 2. 2. 3  Configure  <Post  Name>’s  LNS  network  configu¬ 
ration  tool  (NOT): 

•  Upgrade  NOT  licensing  as  required. 

•  Configure  NOT  drawings  and  displays,  if  appli¬ 
cable,  to  clearly  display  building  DDC  systems. 

3.2.3  Incorporate  each  DDC  system  into  the  UMCS  Monitoring 
and  Control  Software: 
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3.2.3. 1  Create  graphic  display  pages  for  each  DDC  sys¬ 
tem: 

•  To  the  greatest  extent  possible  graphics  for  similar 
systems  shall  be  the  same. 

•  Graphics  shall  provide  monitoring  and  override 
points  as  shown  on  the  Points  Schedules. 

3. 2. 3. 2  Configure  Scheduling,  Alarming  and  Trending  func¬ 
tionality  for  the  building  system  as  shown  on  the 
Points  Schedules. 

3. 2. 3. 3  Configure  supervisory  control  functions  such  as 
demand  limiting,  load  shedding  or  optimum 
start/stop,  if  applicable. 

3.2.4  Create  network  variable  bindings  for  communication  be¬ 
tween  building  systems,  if  applicable. 

3.2.5  Reconfigure  building  DDC  devices  that  poll  for  network 
variables,  particularly  Local  Display  Panels  (LDPs),  to  use 
the  new  domain-subnet-node  addressing  for  the  building 
DDC  system. 

3.3  Contractor  shall  demonstrate  completed  integration  to  the  Govern¬ 
ment.  This  demonstration  shall  show  all  work  performed  and  shall  be 
sufficient  to  familiarize  the  Government  the  interface  to  the  integrated 
systems. 

4.0  GOVERNMENT  FURNISHED  INFORMATION: 


Specifier  note:  Include  all  drawings  and  documentation  required  to  docu¬ 
ment  the  building  system  for  integration.  The  following  list  contains  some 
suggested  drawings,  not  all  of  which  may  be  needed.  For  example,  the 
ductwork  layout  drawing  may  not  be  needed  by  the  integrator  if  user  dis¬ 
plays  do  not  include  ductwork  information. 


4.1  Control  system  drawings  notably  including  the  Points  Schedule  draw¬ 
ing^) 

4.2  [Floor  plan  drawings] 

4.3  [Ductwork  layout  drawings] 

4.4  [Mechanical  drawings] 

4.5  [Electrical  drawings] 

4.6  [Other  drawings  as  indicated  by  <Post  Name>  or  the  <Post  Name> 
System  Integrator] 
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Specifier  note:  The  integrator  is  required  to  update  licensing  and  drawings 
in  the  network  configuration  tool  (NCT).  This  may  require  them  to  purchase 
additional  licensing  and  requires  knowledge  of  the  particular  NCT  the  instal¬ 
lation  uses.  Provide  documentation  of  the  NCT,  including  information  on  the 
licensing  (if  the  software  requires  licenses,  how  many  if  has,  how  many  are 
used  etc)  so  that  the  integrator  can  determine  the  cost/effort  involved  in 
meeting  this  requirement. 


4.7  [Network  Configuration  Tool  (NCT)  licensing  information  including 
NCT  model,  manufacturer,  revision  and  license  status.] 

5.0  DELIVERABLES: 

5.1  Summary  listing  of  all  M&C  software  edits,  changes,  and  updates  ac¬ 
complished  as  part  of  system  integration.  Format  shall  be:  Hardcopy 
and  MS-Word  or  PDF  on  CD-ROM. 

5.2  Product  data  including  product  data  sheets  and  computer  software 
supplied  under  this  contract  as  specified  in  UFGS  25  10  10.  Format 
shall  be:  Hardcopy  and  MS-Word  or  PDF  on  CD-ROM  of  all  data 
sheets,  plus  computer  software  on  CD-ROM. 

5.3  Licensing  information  for  all  software  provided  or  modified  as  under 
this  contract  as  specified  in  UFGS  25  10  10.  Format  shall  be:  Hard¬ 
copy  and  electronic  file  on  CD-ROM. 

5.4  Final  As-Built  Drawings  as  specified  in  UFGS  25  10  10.  Format  shall 
be:  11x17  inch  hardcopy  and  MS-Excel  on  CD-ROM. 


Specifier  note:  Provide  the  notification  time  which  must  be  given  for  the 
demonstration  of  the  integration  and  who  must  be  notified. 


6.0  SCHEDULE:  The  performance  period  shall  be  from  <expected  date  of  DDC 
system  completion/acceptance>  until  <two  months  from  start  or  period 
of  performance:*.  Notice  of  demonstration  of  completed  integration  shall  be 
given  to  [point  of  contact]  no  less  than  [one  week]  before  demonstration. 
Schedule  impacts,  for  any  cause,  will  be  brought  to  the  attention  of  <the 
COR>  and  the  Contracting  Officer  immediately.  The  contractor  shall  provide 
a  proposed  resolution  and  basis  for  delay. 
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Appendix  G:  DDC  Integration  Process  via 
MIPR 


This  document  is  a  draft  of  the  process  through  which  new  direct  digital 
control  (DDC)  systems  are  integrated  into  the  Fort  Bragg  Utility  Monitor¬ 
ing  Control  System  (UMCS).  The  process  defines  the  roles  and  responsi¬ 
bilities  of  Fort  Bragg  (Bragg),  Huntsville  Support  Center  (HNC),  and  Sa¬ 
vannah  District  (SAS).  In  general,  the  basic  approach  includes  SAS 
issuance  of  a  MIPR  (using  construction  project  funds)  to  HNC  who  in  turn 
awards  a  contract  for  system  integration. 

Note  that  the  steps  listed  here  describe  what  must  be  done  but  do  not 
specify  all  details  on  how  each  organization  will  accomplish  that  task.  For 
example,  Item  l  does  not  identify  how  SAS  confirms/assures  that  funding 
is  programmed  -  it  is  expected  that  SAS  knows  how  to  do  this  and  will  be 
able  to  do  so. 


Table  2.  Steps  for  obtaining  integration. 


# 

Step 

Comments  /  Notes 

1. 

In  the  planning  stage  SAS  confirms/assures  that 
there  are  funds  programmed  for  UMCS  integration 
and  sets  aside  0.5%  of  the  facility  cost  to  pay  for 
system  integration.  More  definitive/accurate  pric¬ 
ing  may  be  identified  after  the  first  several  pro¬ 
jects  have  been  completed. 

2. 

In  the  planning  stage  SAS  sends  an  email  alert  to 
HNC  and  Fort  Bragg  that  a  UMCS  DDC  integration 
project  is  being  planned. 

-Email  subject  line:  [Bldg  or  project  number]  inte¬ 
gration  to  UMCS 
-Email  content: 

Notify  HNC  that  a  request  for  UMCS  DDC  integra¬ 
tion  services  is  forthcoming  and  to  provide  an  es¬ 
timated  date  when  the  integration  services  SOW 
(described  in  step  3)  will  be  sent  to  HNC. 

Advance  notification  to  Fort  Bragg  DOIM  that  an  IP 
drop  and  IP  address  on  the  controls  VLAN  will  be 
needed  and  will  be  officially  requested  later  (see 
step  #7). 

Send  email  to: 

HNC: 

Donnie.R.Lambert(S),usace.armv.mil 
Fort  Bragg  DOIM: 

i  ose.troche  1  (3),us.  armv.mil 

Cc: 

steven.  m.  dunnins(2),us .  armv.mil 
i  ennifer.mckenzie(2),us. aimv.mil 
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# 

Step 

Comments  /  Notes 

3. 

Once  the  design  has  progressed  to  the  appropri¬ 
ate  point: 

SAS  sends  the  ‘UMCS  DDC  Integration  SOW’  to 

HNC  so  that  HNC  can  obtain  pricing  for  the  inte¬ 
gration.  Additional  requirements  and  details  may 
well  be  identified  after  Fort  Bragg  has  established 
their  UMCS.  Consequently,  the  SOW  may  need  to 
be  updated.  For  example,  floor  plan  ductwork 
drawings  may  need  to  be  provided  to  support  de¬ 
velopment  of  UMCS  graphical  displays  that  show 
spaces/zones  serviced  by  each  air  handler. 

SAS  indicates  (in  the  UMCS  DDC  Integration  SOW 
or  body  of  the  email)  the  planned/desired  location 
of  the  IP  drop. 

SAS  is  the  owner  of  the  UMCS  DDC  Integration 

SOW  and  will  maintain/update  it  as  needed. 

Send  SOW  to: 

HNC 

Donnie.R.Lambert(S),usace.armv.mil 
Fort  Bragg  DOIM: 

i  ose.troche  1  (3),us.  armv.mil 

4. 

HNC  obtains  pricing  for  integration  based  on  the 
SOW  provided  by  SAS  in  step  3. 

5. 

HNC  provides  cost/pricing  to  SAS  including:  Cost 
for  Integration,  HNC  admin/contracting  fees,  con¬ 
tract  management,  and  any  technical  assis¬ 
tance/reviews  necessary. 

HNC  technical  staff  will  serve  as  the  HNC  contract¬ 
ing  officer’s  technical  representative  (COTR)  and 
provide  quality  verification  (QV)  services  including 
verification  that  all  work  described  in  the  UMCS 
DDC  Integration  SOW  has  been  per¬ 
formed/accomplished.  HNC  shall  oversee  imple¬ 
mentation  of  all  related  Integration  steps  (via  in- 
house  staff  or  Contract)  in  this  System  Integration 
Process  (such  as  coordination  with  DOIM  to  obtain 
IP  drop,  etc.).  It  is  anticipated  that,  over  time,  por¬ 
tions  or  all  of  this  responsibility  may  be  transferred 
to  Fort  Bragg  DPW  staff  (such  as  an  OMD  staff 
member) 

6. 

SAS  MIPRs  funds  to  HNC.  MIPR  wording: 

Provide  integration  services  as  described  in  UMCS 
DDC  Integration  SOW  dated  [  ]. 

7. 

UMCS  Information  Management  Officer  (IMO)  re¬ 
quests  an  IP  drop  and  IP  address  on  the  controls 
VLAN  for  the  BPOC  and  includes  the  estimated 
occupancy  date  in  the  request. 
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# 

Step 

Comments  /  Notes 

8. 

SAS  turns  the  building  over  to  Fort  Bragg  after  the 
following  tasks  have  been  completed: 

SAS  completes  building  construction  including 
Performance  Verification  Test  (PVT)  and  applicable 
Commissioning  of  the  building  control  system(s). 
SAS  verifies  that  the  LonWorks  open  system  re¬ 
quirements  have  been  met.  This  may  be  accom¬ 
plished  using  the  LonWorks  Compliance  Assess¬ 
ment  Tool  being  developed  via  CERL/HNC 
direction/contract. 

9. 

System  Integration  Contractor  can  begin  the  inte¬ 
gration  process  -  installation  of  new  servers, 
graphic  creation,  etc. 

10. 

DOIM  installs  IP  drop 

11. 

System  Integration  Contractor  installs  BPOC  and 
completes  integration  of  building  controls  to 

UMCS. 
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Appendix  H:  Example  Implementation  Plan 

IMPLEMENTATION  PLAN 
For 

[FORT  BRAGG] 

BUILDING  AUTOMATION  SYSTEM 
(draft  4/2/07) 

Workgroup  Members 

•  Steve  Dunning,  Facilities  Maintenance  Division  (FMD)  Work  Leader 

•  Ashley  Gore,  FMD  Work  Leader 

•  Russ  Hayes,  DPW  Mechanical  Engineer 

•  Derrick  McRae,  Mechanical  Engineer 

•  Jennifer  McKenzie,  Energy  Manager 

•  Tom  Patrick,  FMD  Work  Leader 

•  David  Taylor 

•  Jose  Troche  (DOIM) 

•  Vic  Walker,  Operations  Maintenance  Division  (OMD)  Operations  Offi¬ 
cer 

•  Wilhelmina  Pierce  (Corps  of  Engineers  [COE]) 

Purpose 

The  purpose  of  this  document  is  to  describe  [Fort  Bragg’s]  basewide  BAS 
including  the  goals,  features,  and  benefits  of  the  BAS  along  with  a  strategy 
for  successful  implementation,  use  of,  and  support  of  the  BAS. 

Note:  This  document  makes  reference  to  Unified  Facilities  Guide  Specifi¬ 
cations  UFGS-13801  and  15951,  which  have  been  assigned  new  numbers; 
UFGS  25  10  10  and  23  09  23,  respectively. 

Problem 

[Fort  Bragg]  has  two  basic  problems: 

1.  Multiple  brands  of  Direct  Digital  Control  (DDC)  systems  that  are  not  inte¬ 
grated  into  a  common  single-interface  user-friendly  system.  There  are  cur- 
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rently  three  "enterprise"  systems  with  no  overall  plan  to  integrate  all  sys¬ 
tems  into  an  installation  wide  system  or  connect  the  new  "smart"  build¬ 
ings. 

a.  Honeywell  Inc.  has  an  onsite  presence  at  the  Energy  Information  Cen¬ 
ter.  Through  an  ESPC  Honeywell  uses  their  Enterprise  Buildings  Inte¬ 
grator  (EBI)  platform,  which  is  interfaced  to  165  building-level  control 
systems  (installed  by  Honeywell)  including  approximately  50,000 
points  and  approximately  280  energy  meters  (electricity,  gas,  water). 
Honeywell  has  installed  nine  EBI-related  servers.  Four  of  these  (CoGen 
plant,  JSOC,  Main,  and  Energy  Center)  are  networked  to  the  servers  at 
the  Energy  Information  Center,  the  other  five  are  not.  There  are  14 
workstations  located  at  the  Central  plants,  Work  Order  Center,  and  the 
Energy  Information  Center).  Currently  the  system  software  license  in¬ 
cludes  12  simultaneous  users  per  server  with  up  to  40  licensed  users 
possible  (per  server),  there  is  no  contractual  arrangement  to  obtain 
system  integration  services  to  integrate  new  (Honeywell  or  3rd  party) 
LonWorks®  building-level  systems  to  the  EBI  front-end.  The  EBI  sys¬ 
tem  includes  proprietary  elements  including  88  Tridium  JACE  and  96 
Honeywell  C-bus  controllers  where  each  of  these  is  at  the  “building 
level.”  The  JACE  and  C-bus  devices  do  not  accommodate  a  logically  flat 
TP/FT-10  network  connection  (where  the  logically  flat  network  is  cur¬ 
rently  the  preferred  open  systems  approach).  Reportedly,  JACE  devices 
are  no  longer  being  installed  as  it  appears  Honeywell  is  transitioning 
towards  a  logically  flat  architecture.  There  are  143  LonWorks®  con¬ 
trollers  and  15  distributed  input/output  (I/O)  LonWorks®  devices. 

The  distributed  I/O  LonWorks®  devices  are  interfaced  to  Honeywell 
Excel  500  controllers  in  a  supervisory  configuration  thus  not  part  of  a 
logically  flat  LonWorks®  network.  In  addition,  some  of  the  Excel  500 
controllers  are  on  C-bus  network  (not  a  TP/FT-10  LonWorks®  net¬ 
work).  Similarly  there  are  Excel  50  controllers  also  on  a  C-bus  network. 
Both  the  Excel  50  and  500  are  configurable  to  accommodate  a  TP/FT- 
10  network  connection  via  a  card/slot  on  the  controller.  (Information  is 
current  as  of  Mar  07) 

b.  JCI  has  an  onsite  office  that  services  Bragg  and  other  clients.  Through 
“UMCS II”  contract  awarded  by  Huntsville,  JCI  has  installed  a  number 
of  LonWorks®  systems.  Some  of  the  early  systems  used  the  proprie¬ 
tary  NAE  supervisory  controller  device  at  the  building-level.  Later  sys¬ 
tems  reportedly  use  the  JCI  flat  LonWorks®  architecture  and  therefore 
are  (should  be)  in  accordance  with  intent  and  requirements  of  UFGS 
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25  10  10  and  23  09  23.  The  systems  installed  by  JCI  include  33  build¬ 
ings  that  use  JCI  proprietary  N2  communications  bus  and  62  buildings 
that  use  LonWorks®  (presumably  TP/FT-io  bus).  The  first  10  build¬ 
ings  installed  under  EMCS II  contract  were  N2,  the  rest  used 
LonWorks®  TP/FT-io.  There  are  two  LonWorks®  Control  Station 
(LCS-8520)  front-end  operator  workstation  computers  and  a  server, 
but  these  workstations  are  not  “on  the  network”  as  the  JCI  system 
awaits  DITSCAP  (DOD  Information  Technology  Security  Certification 
and  Accreditation  Process)  (or  equivalent  DIACAP)  certification.  In 
addition  there  is  no  contractual  arrangement  to  obtain  system  integra¬ 
tion  services  to  integrate  new  (JCI  or  3rd  party)  LonWorks®  building- 
level  systems  to  the  LCS  front-end.  (Information  is  current  as  of  Mar 

07) 

c.  Yamas.  Pope  Air  Force  Base  (AFB)  through  a  Utility  Energy  Services 
Contract  (UESC)  installed  a  Yamas  (Tridium/JACE)  system  including 
approximately  74  buildings  and  126  meters.  Pope  AFB  becomes  part  of 
Fort  Bragg  through  Base  Realignment  and  Closure  (BRAC)  around 
2011. 

2.  In  addition  to  the  enterprise-level  systems  described  above,  individual 
building-level  DDC  systems  are  procured  on  a  routine  basis.  The  individ¬ 
ual  multi-vendor  systems  are  often  provided  with  laptops,  PCs,  and  soft¬ 
ware  tools  resulting  in  overwhelming  complexity  due  to  the  ordinary  com¬ 
plexity  of  DDC  technology  compounded  by  multiple  tools  from  multiple 
manufacturers.  For  example,  Fort  Bragg  has  14  different  DDC  system  lap¬ 
tops. 

The  end  result  is  potentially  very  useful  mix  of  building  automation  sys¬ 
tems  that  are  of  limited  effectiveness  to  routine  DPW  operations  in  part 
because  the  DPW  has  only  limited  or  no  access  to  the  Honeywell  and  JCI 
systems.  Limitations  include  access  to  the  operator  workstations  for  the 
O&M  activities  and  energy  manager  support  functions. 

Goals  and  Benefits 

The  overall  goal  is  to  obtain  a  basewide  BAS  consisting  of  a  UMCS  (front- 
end)  and  local  control  DDC  systems  that  functions  as  a  single  integrated 
system.  The  BAS  must  be  manageable  and  maintainable.  It  must  also  be 
usable  by  and  functional  for  the  Operations  Maintenance  Division  (OMD), 
the  energy  manager,  and  others.  Over  the  long  term  the  BAS  must  grow 
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with  the  needs  of  the  DPW  and  evolve  into  a  fully  functional  tool  that  is 
supportable  by  and  useful  to  OMD. 

The  BAS  will  perform  and  support  the  following  functions: 

•  Remote  monitoring  of  buildings.  Provide  O&M  staff  and  others  the  ca¬ 
pability  to  easily: 

o  Display  real-time  system/equipment  performance 
o  Set  up  and  collect  trend  data  (for  example;  historical  temperature 
data) 

o  Set  up  alarm  points  including  routing  of  alarms  to  appropriate  per¬ 
sonnel  while  avoiding  the  creation  and  generation  of  nuisance 
alarms 

•  Improve  service  order  process  especially  for  HVAC 

o  Analyze  the  problem  remotely  and  send  the  correct  technician 
o  Identify  the  potential  problem  before  arrival  onsite 
o  Energy  Monitoring  and  Control  System  (EMCS)  alarms  generate 
service  orders,  without  increasing  backlogs 
o  Transition  from  reactive  to  proactive  environment 

•  Improve  customer  service  by  improving  response  time  and  situational 
awareness  before  arriving  on  site.  Ideally  the  DPW  identifies  problems 
before  the  customer  is  aware  of  situation. 

•  Improve  building  occupants  comfort  level 

•  Identify  problems  initially  when  they  are  small  and  cost  less  to  fix  in¬ 
stead  of  complete  replacement  due  to  system  failure. 

•  Support  energy  savings 

o  Temperature  set  backs  during  nights  and  weekends  including 
scheduled  start-stop  of  air  handling  units 
o  Monitoring  of  energy  usage  and  cycling  of  mechanical  and  electrical 
equipment  during  energy  peaks  to  reduce  electrical  power  demand 
o  Improved  maintenance  and  thus  performance  of  equipment 
o  Automate  other  processes  such  as  parking  lot  and  baseball  field 
lighting 

•  Generate  reports. 
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BAS  Characteristics 

General  Description 

The  [Fort  Bragg]  BAS  will  be  based  on  open  systems  technology  specified 
in  two  Unified  Facilities  Guide  Specifications  including  LonWorks®  tech¬ 
nology  and  ANSI/CEA  standard  709.1  communications  protocol.  One  is 
for  building  level  controls  used  when  a  facility  is  designed  and  con¬ 
structed.  This  is  UFGS  23  09  23,  Direct  Digital  Control  (DDC)  for  HVAC 
and  Other  Building  Systems  is  for  building  level  controls  used  when  a  fa¬ 
cility  is  designed  and  constructed.  The  other  is  UFGS  25  10  10,  Utility 
Monitoring  and  Control  System  for  a  “front  end”  or  a  base  wide  interface 
to  the  building  level  systems.  Both  of  these  specifications  are  intended  to 
specify  and  procure  as  open  a  system  as  is  possible.  An  open  system  is  one 
where  there  is  no  future  dependence  on  the  original  installing  contractor. 
For  the  purposes  of  procurement,  this  means  that  there  is  no  sole  source 
dependence  on  any  contractor  for  future  system  additions,  upgrades,  or 
modifications.  An  open  system  helps  to  avoid  proprietary  sole  source  pro¬ 
curement  in  accordance  with  government  procurement  rules.  In  practice, 
single-source  procurement  is  usually  necessary  for  the  UMCS,  but  can  be 
avoided  for  the  building-level  DDC  systems.  In  the  case  of  the  UMCS,  the 
procurement  of  the  base  wide  UMCS  can  be  open  competition  resulting  in 
a  single  provider  over  an  extended  term.  This  is  discussed  under  “Path 
Forward.” 

Operator  Workstations  and  Server(s) 

There  will  be  multiple  operator  workstations  (OWS)  for:  OMD  chief,  OMD 
shop  supervisor,  OMD  work  leaders,  OMD  common  area  for  use  by  OMD 
staff,  Energy  Manager,  and  DPW  Director  with  several  levels  of  password 
access  to  the  various  features.  A  web-based  Graphical  User  Interface  (GUI) 
will  be  considered.  Workstations  will  display  information  and  graphics  as 
specified  in  UFGS  25  10  10  including  floor  plans  (except  for  sensitive  areas 
such  as  SKIFs) 

LDPs 

There  will  be  a  local  display  panel  (LDP)  mounted  on  or  in  each  enclosure 
located  in  a  mechanical  room.  LDPs  can  permit  both  display  and  adjust¬ 
ment  of  certain  control  system  parameters  such  as  control  inputs,  outputs, 
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and  setpoints.  The  UFGS  23  09  23  guide  specification  calls  for  the  de¬ 
signer  to  decide  and  thus  specify  if  LDPs  will  permit  display,  adjustment, 
or  both  display  and  adjustment  of  parameters.  This  decision  should  be 
made  based  on  maintenance  staff  input.  Specifying  the  functionality  is  ac¬ 
complished  by  showing  the  required  functions  in  a  Points  Schedule  draw¬ 
ing  where  this  drawing  is  referenced  in  UFGS  23  09  23.  This,  along  with 
other  designer  options  contained  in  the  UFGS  23  09  23  specification 
should  be  reviewed  by  the  DPW  so  that  the  DPW  and  particularly  the 
maintenance  staff  have  an  opportunity  to  provide  input  to  system  design 
and  specification.  These  preferences  should  be  documented  in  the  IDG. 

IT  network 

The  BAS  will  use  the  existing  high  speed  basewide  IT  network  for  commu¬ 
nication  between  building-level  DDC  systems  and  the  UMCS  workstations. 
All  applicable  hardware  and  software  will  have  DOIM/DITSCAP 
(DIACAP)  approval/certification.  Wireless  technology  will  be  considered 
where  the  existing  IT  infrastructure  is  not  suitable  (for  example,  due  to 
cost).  Wireless  communication  could  drastically  reduce  some  of  the  capital 
cost,  but  it  currently  is  not  approved  at  the  Army  installation  level.  There 
are  a  lot  of  hurdles.  Wireless  is  not  currently  authorized  to  access  the  do¬ 
main  and  will  need  DITSCAP  Interim  Authority  To  Operate  (IATO)  ap¬ 
proval.  The  installation  does  not  have  the  backbone  communication  infra¬ 
structure  to  support  wireless  transmission  especially  for  WiMax. 

Building  Control  Network 

All  project  will  include  a  TP/FT-10  building  control  network  and  all  DDC 
devices  will  be  connected  to  this  network.  Building -level  designs  will  show 
the  proposed  location  of  the  Building  Point  of  Connection  (BPOC)  (to  be 
installed  by  the  System  Integrator)  and  the  TP/FT-10  network  cabling  (in¬ 
stalled  by  the  building-level  contractor)  will  extend  to  that  location.  The 
BPOC  (CEA  852  router)  locations  shall  not  be  in  communication  closets. 
They  may  be  in  electrical  closets  or  in  approved  mechanical  rooms  in  ap¬ 
proved  and  appropriate  enclosures. 

Laptops  with  NCT 

The  primary  O&M  tool  will  be  a  laptop  with  a  network  configuration  tool 
(NCT)  software.  Five  individuals  within  OMD  will  possess  NCT  laptops. 
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Software 

Other  software  packages  provided  by  Contractors  (such  as  programming 
software)  will  reside  with  the  system  integrator  (and  one  OMD  POC).  Pro¬ 
gramming  software  should  only  be  needed  to  initially  program  “program¬ 
mable”  controllers  (by  the  installing  Contractor).  All  programmable  con¬ 
troller  settings  necessary  for  O&M  activities  will  be  exposed  as 
LonWorks®  SNVTs  or  Configuration  Property  Types  (CPTs)  and  thus  ac¬ 
cessible  using  the  NCT  or  OWS. 

Controllers 

Controllers  come  in  two  basic  varieties:  programmable  and  application 
specific.  Programmable  controllers  will  be  avoided.  Complex  applications 
may  require  them,  but  as  a  rule  application  specific  controllers  (ASCs)  will 
be  given  preference.  Contractors  will  be  encouraged  to  use  ASCs  due  to 
their  relative  simplicity.  Programmable  controllers  with  plug-ins  will  be 
given  preference  over  those  without  plug-ins.  Note  a  plug-in  is  a  software 
tool  that  can  be  launched  from  the  NCT  and  can  be  used  to  remotely  re¬ 
program  a  programmable  controller).  ASCs  will  be  provided  with  plug-ins 
as  specified  in  UFGS  23  09  23.  This  requirement  must  be  enforced  by  the 
USACE  Construction  office. 

Miscellaneous 

Controls  and  equipment  must  be  maintenance  accessible.  Equipment 
must  be  appropriate.  The  Workgroup  will  generate  a  list  of  requirements 
and  pursue  incorporating  these  requirements  into  the  IDG. 

Control  Devices  and  Interfaces 

•  Pneumatic  actuation  of  valves  and  dampers  is  preferred  over  electric 
actuators  due  primarily  to  reliability  and  simplicity.  Positive  position¬ 
ers  should  be  avoided  unless  deemed  necessary  for  the  application  (for 
example,  due  to  the  need  for  moving  large  volumes  of  air  or  for  device 
sequencing). 

•  Filter  alarms.  Differential  pressure  switches  used  to  sense  loaded 
(dirty)  air  filters  are  problematic  (for  a  variety  of  reasons).  The  current 
preference  is  to  not  use  these,  but  instead  generate  a  time-based  low- 
priority  alarm  (perhaps  via  e-mail)  where,  for  example,  after  3  months 
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an  alarm  is  generated  to  notify  OMD  that  a  particular  filter  is  due  to  be 
changed. 

•  Fan  coil  unit  condensate  drain  overflow  switch  monitoring  and  alarm. 
Additional  preferences  may/will  be  added  as  they  are  identified. 

UMCS  Management 

The  UMCS  will  be  managed  by  the  System  Integrator  (SI)  and  by  the 
UMCS  Workgroup  (or  their  designated  in-house  individual)  and  with  clear 
distinction  of  roles  and  responsibilities.  The  Workgroup  will  define  SI 
roles  and  responsibilities  and  will  identify  a  mechanism  to  obtain  these 
long  term  services.  In  summary,  the  SI  will  review  DDC  submittals,  man¬ 
age  DDC  Contractor  submittals  (Points  Schedules,  LNS  plug-ins,  LNS  da¬ 
tabases,  XIF  files),  integrate  new/renovated  DDC  systems  into  the  BAS, 
maintain  the  LNS  database,  update  the  Graphical  User  Interface  (GUI)  for 
added  buildings,  manage  the  overall  maintenance  of  the  UMCS  (software 
updates,  etc.),  coordinate  all  networking  activities  with  DOIM,  and  man¬ 
age  and  maintain  laptop  hardware  and  software. 

Systems  Integration  and  Support 

A  system  integrator  (SI)  will  be  perform  systems  integration  and  UMCS 
management  services  as  defined  above  under  UMCS  Management.  In  ad¬ 
dition,  the  SI  will  provide  support  services  potentially  including  embed¬ 
ding  technical  staff  with  OMD  to  provide  operation  and  maintenance  sup¬ 
port  and  on  the  job  training.  SI  requirements  need  to  be  further  defined  as 
described  under  Path  Forward. 

Support  Structure 

Successful  design,  specification,  procurement,  operation,  maintenance, 
and  expansion  of  the  [Fort  Bragg]  BAS  includes  the  following  support 
structure: 

•  UMCS  Workgroup.  Defines  and  executes  the  Implementation  Plan. 
Holds  periodic  meetings  to  assess  progress,  make  changes  to  the  plan 
as  necessary,  and  provides  general  oversight  and  management  of  the 
BAS. 

•  System  Integrator.  Performs  UMCS  management  and  integration  ser¬ 


vices. 
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•  Directorate  of  Public  Works  (DPW)  Engineering  Design.  Will  work 
with  the  Workgroup  to  define  BAS  specifications  for  in-house  designs. 
These  specifications  must  be  tailored  to  the  specific  contracting 
mechanism  where  these  mechanisms  include:  [Job  Order  Contract,  ] 

•  Directorate  of  Contracting .  May  be  needed  to  help  identify  a  contract¬ 
ing  vehicle  to  obtain  the  initial  UMCS  and  the  long  term  services  of  a 
Systems  Integrator  (SI). 

•  Directorate  oflnformation  Management  (DOIM).  Will  work  with  the 
Workgroup  and  the  Huntsville  Contractor  to  identify  DOIM  require¬ 
ments.  This  will  result  in  pertinent  requirements  to  be  included  in  BAS 
project  specifications  along  with  an  agreement  between  DOIM  and  the 
Workgroup  on  methods  and  procedures  to  be  followed. 

•  DPW  Master  Planning  Office.  Will  work  with  the  Workgroup  to  ensure 
that  the  Installation  Design  Guide  (IDG)  reflects  requirements  for  the 
BAS. 

•  DPW  Maintenance  Staff.  Provides  input  to  Workgroup.  Reviews  the 
Implementation  Plan.  Designated  OMD  staff  will  be  trained  as  DDC 
Specialists.  The  training  will  include  basic  laptop  usage,  NCT  software, 
LNS-plug-ins,  DDC  system  acceptance  procedures.  All  OMD  HVAC 
O&M  staff  will  be  trained  on  basic  PC  usage  and  fundamental  usage  of 
the  centrally  located  OWS  (how  to  pull  up  and  view  points  and  alarms). 

•  USACE  District  Office  Engineering  Design.  Ensures  that  designs  for 
new  facilities  and  renovations  of  building  control  systems  are  consis¬ 
tent  with  the  Implementation  Plan.  Reviews  the  Implementation  Plan. 

•  USACE  Construction  Office.  Works  with  Workgroup  to  develop  a 
Building  Acceptance  methodology.  Reviews  the  Implementation  Plan. 

Path  Forward 

Plan  Documentation 

The  UMCS  Workgroup  will  review  and  refine  the  Implementation  Plan. 

The  plan  will  be  a  living  document  and  coordinated  with  other  interested 

and  involved  parties  including  those  listed  under  the  Support  Structure. 

The  UMCS  workgroup  reviewed  the  initial  draft  Plan  on  27  February  2007. 
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Select  UMCS 

Fort  Bragg  needs  to  select/procure  a  basewide  single-vendor  UMCS  to 
serve  as  the  front-end  (brain)  for  all  their  BAS  systems.  This  is  a  three  step 
process. 

1.  Define/Specify  UMCS.  The  UMCS  Workgroup  must  edit  the  UMCS  re¬ 
quirements  in  the  generic  “UMCS  and  Systems  Integrator  RFP/SOW”* 
contained  in  the  “IMCOM  LonWorks®  Building  Automation  Systems  Im¬ 
plementation  Plan”  and  edit  UFGS  25  10  10  to  include  [Fort  Bragg]  spe¬ 
cific  requirements.  In  doing  so  the  Workgroup  needs  to  make  sure  the 
RFP/SOW  and  UFGS  25 10 10  include  [Fort  Bragg’s]  desired  UMCS  re¬ 
quirements,  features,  functions,  and  capabilities,  particularly  those  listed 
in  Goals  and  BAS  Description  portions  of  this  (Fort  Bragg’s)  Implementa¬ 
tion  Plan.  The  Workgroup  will  need  to  coordinate  with  and  include  [Fort 
Bragg]  DOIM/IT-related  UMCS  requirements  (need  for  IP  network  drops, 
providing  static  IP  addresses,  etc.). 

2.  Define/Specify  System  Integration  Services  and  Support  Services.  (This 
can  be  considered  integral  to  the  above  step).  The  UMCS  Workgroup  must 
edit  the  UMCS  requirements  in  the  generic  “UMCS  and  Systems  Integra¬ 
tor  RFP/SOW”  contained  in  the  “IMCOM  LonWorks®  Building  Automa¬ 
tion  Systems  Implementation  Plan”  and  edit  UFGS  25 10  10  to  include 
[Fort  Bragg]  specific  requirements.  The  UMCS  Workgroup  must  identify 
SI  services/requirements  and  related  support  services. 

3.  Procure  UMCS  and  SI  Services.  The  UMCS  Workgroup  must  identify  an 
approach  to  procure  the  single  vendor  basewide  UMCS  along  with  SI  ser¬ 
vices.  In  the  case  of  SI  services,  one  option  is  to  award  an  SI  contract  inde¬ 
pendent  of  the  UMCS  contract  where  the  SI  contract  is  for  a  long  term 
such  as  5  years  where  a  single  entity  performs  all  SI  services  as  new  build- 
ings/control  system  are  installed/ constructed.  Another  option  is  to  include 
SI  services  requirements  in  each  new  building-level  DDC  system  contract 
where  each  building-level  Contractor  is  responsible  for  system  integration 
(where  the  Contractor  may  choose  to  do  the  SI  him/herself  or  may  hire 
whomever  installed  the  UMCS). 


*  RFP  =  “request  for  proposal. 
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Some  notable  and  miscellaneous  issues/tasks  related  to  the  above  steps 
include: 

•  Make  sure  that  the  items  listed  in  the  Goals  and  BAS  Description  por¬ 
tions  of  this  Plan  are  incorporated  into  contract  documents. 

•  Develop  LonWorks®  Points  Schedules.  Identify  and  show  mandatory 
and  optional  SNVT-related  points.  Include  chillers  and  boilers.  Con¬ 
sider  standard  SNVT  naming  convention.  Consider  standard  sequence 
of  control.  CERL  will  take  the  lead  on  this. 

•  Identify  arrangement  for  potentially  embedding  SI  maintenance  staff 
with  OMD. 

•  NCT  update  methodology.  Automatic  versus  manual  updates  of  LNS 
database. 

•  O&M  tool  options  such  as  personal  digital  assistant  (PDA)  or  portable 
LDP  with  TP/FT-io  dongle. 

•  Require  SI  to  monitor  building  usage  and  ratchet  down  when  troops 
are  deployed. 

•  Division  of  responsibility  between  the  UMCS/DDC/SI  contractors  and 
DPW/OMD 

•  Compare  requirements  to  Fort  Hood  contractual  arrangement. 

•  All  PCs  may  be  transitioning  to  dumb  terminals.  What  is  the  impact? 

Integrate  Existing  LonWorks®  Buildings 

The  UMCS  Workgroup  will  consider  the  need  and  technical  potential  for 
connecting  existing  LonWorks®  buildings  into  the  BAS  (non-  LonWorks® 
buildings  are  a  lower  priority  and  will  be  considered  by  the  Workgroup  at  a 
later  date  on  a  case-by-case  basis).  To  this  end,  the  UMCS  Workgroup  will 
assist  in  the  execution  of  a  Contract  being  awarded  by  Savannah  District 
(SAS)  to  obtain  external  assistance  where  the  contractor  will  survey  exist¬ 
ing  BAS  elements  to  identify  existing  LonWorks®  controls  and  local  con¬ 
trol  contractor  support  capabilities  as  part  of  identifying  implementation 
requirements/approach.  As  part  of  this,  the  UMCS  Workgroup  will  iden¬ 
tify  buildings  to  be  surveyed  on  a  priority  basis  where  mini-plants  will 
have  high  priority  as  will  new  buildings  and  those  with  a  large  footprint. 
The  SAS  contractor  will  assess  the  potential  and  cost  for  pulling  local  con¬ 
trol  system(s)  into  the  basewide  UMCS.  A  rough  estimate  is  about  $2000 
to  provide  and  install  a  CEA-852  router  under  the  assumption  that  the  IP 
network  is  available,  the  TP/FT-10  building  control  network  exists  and 
does  not  need  to  be  extended,  and  the  building  control  system  contains 
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LNS  compatible  devices  including  LNS-plug-ins  and  a  current  LNS  data¬ 
base.  The  Contractor  will  develop  SOW  requirements  to  perform  the  inte¬ 
grations. 

Savannah  District  Coordination 

The  UMCS  Workgroup  will  coordinate  with  Savannah  District  on  design 
and  specification  requirements  for  future  Operations  and  Maintenance, 
Army  (OMA)  and  MILCON  projects  connecting  into  the  installation  wide 
BAS.  One  issue  is  that  current  and  future  MILCON  does  not  support  run¬ 
ning  fiber  to  the  mechanical  rooms  or  connecting  to  existing  installation 
systems.  The  installation  has  smart  buildings  that  do  not  have  any  place  to 
send  their  data. 

IDG  Update 

The  UMCS  Workgroup  will  incorporate  BAS  requirements  into  the  Instal¬ 
lation  Design  Guide  (IDG).  Of  particular  interest  is  the  UFGS  23  09  23 
guide  specification,  which  contains  various  designer  options/selections 
that  will  impact  features  and  functions  of  installed  DDC  systems.  These 
options  should  be  reviewed  by  the  DPW  so  that  the  DPW  and  particularly 
the  maintenance  staff  have  an  opportunity  to  provide  input  to  system  de¬ 
sign  and  specification.  These  preferences  should  be  documented  in  the 
IDG.  Many  of  these  UFGS  23  09  23  options/selections  are  specified  by 
showing  the  required  functions  in  a  Points  Schedule  drawing  where  this 
drawing  is  referenced  in  UFGS  23  09  23.  The  IDG  might  include  these 
drawings. 

On  Site  Seminar 

The  UMCS  Workgroup  will  assist  with  and  participate  in  an  on-site  train¬ 
ing  and  coordination  seminar  conducted  by  ERDC-CERL,  SAS,  and  HNC 
to  help  further  define  the  Implementation  Plan. 

UMCS  and  DDC  Training 

The  UMCS  Workgroup  will  identity  training  needs  and  a  strategy  for  ob¬ 
taining  needed  training  such  as  including  Fort  Bragg  specific  training  re¬ 
quirements  in  construction  contracts  and  in  the  UMCS/SI  RFP/SOW  de¬ 
scribed  under  “Select  UMCS.” 
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BAS/DDC  System  Acceptance  Methodology 

The  UMCS  Workgroup  will  define  a  BAS  building-level  DDC  system  accep¬ 
tance  methodology  checklist/procedures.  The  acceptance  process  will  in¬ 
clude  design  review  by  DPW/OMD  along  with  procedures  for  construction 
inspectors  and  DPW  to  help  ensure  that  all  construction  projects  comply 
with  the  requirements  of  the  BAS. 

Energy  Conservation  Investment  Program  (ECIP)  and  Other  Funded 
Support 

The  UMCS  Workgroup  will  identify  and  seek  funding  support  for  the  Fort 
Bragg  BAS.  This  includes  developing  an  FY09  ECIP  proposal  in  support  of 
the  basewide  BAS. 
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Appendix  I:  UFGS  23  09  23  LonWorks 
Compliance  Assessment  Tool  Checklist 


Priority 

Category 

Para  # 

High 

General 

1.4.1.a 

High 

General 

1.4.1.b 

High 

General 

1.4.1.f 

Med 

Other/Misc 

1.8.f 

High 

DDC  Hardware 

1.12.1.b 

High 

DDC  Hardware 

1.12.2.a 

Med 

DDC  Hardware 

1.12.2. b 

High 

DDC  Hardware 

1.12.2.C 

Med 

DDC  Hardware 

1.12.2.d 

Specification  Requirement 


Control  system  shall  be  an  open  implementation  of  the  CEA- 
709.1B  communications  protocol  using  LonMark  Standard  Net¬ 
work  Variable  Types 


Limited  Test: 
Submittals  Only 


Detailed  Test: 
Network  Configuration  Tool 


Review  Points  Schedules,  inspect  devices  for  SNVT  Review  LNS  database,  inspect  nodes  for  SCPT  configura- 

variables  with  SNVT  type  identified.  Look  for  any  UNVTs  tion  parameters  and  SNVT  variables.  Check  for  variable 
on  the  Points  Schedule  (or  any  UNVTs  for  points  that  are  bindings  between  Scheduler  and  Equipment  nodes  of 
used  on  the  controller).  UNVTs  are  not  in  compliance  SNVT  state_occupancy.  Check  for  SNVT  HVAC_occupancy 
with  the  intent  of  the  specification.  exposed  on  equipment  nodes.  Check  for  UNVT 


LNS  services  shall  be  used  for  all  network  management.  A  copy  of  Ensure  LNS  database  submitted  as  part  of  record- 
the  LNS  database  shall  be  submitted  to  the  project  site.  drawings. 


Restore  the  submitted  LNS  database  to  the  network 
configuration  tool.  Open  the  database  and  inspect  the 
nodes.  Verity  the  nodes  match  the  submitted  equipment 
lists. 


All  necessary  documentation,  configuration  information,  configura-  Review  submitted  As-Built  documentation  and  software  provided  by  contractor.  Ensure  that  plug-in  and  program- 
tion  tools,  programs,  drivers,  and  other  software  shall  be  licensed  ming  software  is  provided  for  all  controllers  detailed  in  Record  Drawings  and  points  schedules.  Ensure  that  proof  of 
to  and  otherwise  remain  with  the  Government  such  that  the  software  licensing  listing  Govt  as  owner  exists  in  the  submittal  package. 

Government  or  their  agents  are  able  to  perform  repair,  replace¬ 
ment,  upgrades,  and  expansions  of  the  system  without  subse¬ 
quent  or  future  dependence  on  the  Contractor. 

The  HVAC  control  System  Operation  and  Maintenance  Instructions  Review  record  drawings  for  controller  printouts  consisting  of  a  printed  table  of  each  controller's  configuration  pa- 
shall  include  printouts  of  configuration  settings  for  all  devices.  rameters 


work  if  a  backbone  is  utilized. 


CEA-709.1B  Routers 


Review  network  riser  diagram.  Ensure  that  only  FT-10  routers  and  devices  exist  in  the  riser  diagram  except  the 
BPOC,  which  should  be  a  IP  to  FT-10  network  device. 


Point  of  Connection  (BPOC)  location  may  be  connected  to  the 
backbone. 


network  in  doubly-terminated  bus  topology  in  accordance  with 
CEA-709.3 


Review  record  drawings  and  verify  that  local  control  bus  has  network  layout  documented  with  location  of  terminators 
identified.  The  TP/FT-10  network  should  be  a  single  strait  bus  with  no  single  drops  exceeding  3  feet.  Termination 
should  occur  at  each  end  of  the  local  control  bus. 


The  local  control  busses  shall  be  installed  such  that  no  Review  riser  diagram  and  ensure  that  no  channel  is  configured  in  such  a  fashion  that  more  than  two  CEA-709.1B 

node(device  connected  to  the  control  network)  has  more  than  two  routers  and  repeaters  exist  between  the  backbone  and  the  nodes 
CEA-709.1B  Routers  and  CEA-709.3  Repeaters  (in  any  combina¬ 
tion)  between  it  and  the  backbone,  including  the  router  connected 
to  the  backbone. 
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10  High  DDC  Hardware 

11  Med  DDC  Hardware 


12  High  DDC  Hardware 


13  High  DDC  Hardware 


14 

High 

DDC  Hardware 

2.14.3.a 

15 

High 

DDC  Hardware 

2.14.b 

16  Med  DDC  Hardware 


Specification  Requirement 


Limited  Test: 
Submittals  Only 


Detailed  Test: 
Network  Configuration  Tool 


2.4.1.1  CEA-709.1B  Routers  (including  routers  configured  as  repeaters)  Review  product  data  sheets  and  ensure  that  all  installed  routers  are  CEA-709.1B  certified, 

shall  meet  the  requirements  of  CEA-709.1B  and  shall  provide 
connection  between  two  or  more  CEA-709.3  TP/FT-10  channels. 

2.4.2  Gateways  shall  perform  bi-directional  protocol  translation  from  one  Review  product  data  sheets  and  ensure  that  all  installed  gateways  incorporate  one  TP/FT10  network  port  and  one 
non  CEA-709.1B  protocol  to  CEA-709.1B.  Gateways  shall  incorpo-  proprietary  network  port.  Review  riser  diagram  and  confirm  that  proprietary  network  connection  and  TP/FT10  net- 
rate  exactly  two  network  connections:  one  shall  be  for  connection  work  connections  exist 
to  a  TP/FT-10  network  in  accordance  with  CEA-709.3  and  the 
second  shall  be  as  required  to  communicate  with  the  non-CEA- 
709. IB  network. 

2.14.1.C  All  DDC  hardware  shall  incorporate  a  TP/FT-10  transceiver  in  Review  product  data  sheets  and  ensure  that  all  installed  nodes  incorporate  a  TP/FT  10  transceiver.  Review  Record 

accordance  with  CEA-709.3  and  connections  for  TP/FT-10  control  drawings  device  details  to  determine  the  TP/FT  10  transceiver  is  set  for  operation  if  jumper  settings  are  required, 
network  wiring.  It  shall  not  have  connections  to  any  other  network  Note:  Transceiver  designation  may  be  TP/FT-10,  FT-10,  FTT-10,  or  FTT-10A  depending  upon  manufacturer, 
media  type  and  it  shall  communicate  via  the  CEA-709.3  protocol 
only. 


2.14.1.h  It  shall  have  all  functionality  specified  and  required  to  support  the 
application  (Sequence  of  Operation  or  portion  thereof)  in  which  it 
is  used,  including  but  not  limited  to:  (1)  It  shall  provide  input  and 
output  SNVTs  as  specified  and  required  to  support  the  sequence 
and  application  in  which  it  is  used.  (2)  It  shall  be  configurable  via 
standard  or  user-defined  configuration  parameters  (SCPT  or 
UCPT),  SNVT  network  configuration  inputs  (NCI),  or  hardware 
settings  on  the  controller  itself  as  specified  and  as  required  to 
support  the  sequence  and  application  in  which  it  is  used. 

2.14.3.a  ASCs  shall  be  LonMark  Certified. 


Review  points  schedules  and  product  data  sheets. 
Inspect  nodes  for  SCPT  configuration  parameters  and 
SNVT  variables.  Verify  that  points  defined  in  sequence 
and  points  list  are  represented  by  SNVT  variables  in  the 
point  schedules.  Verify  that  configuration  parameters  as 
required  for  the  sequence  of  operation  are  identified 


Review  LNS  database,  inspect  nodes  for  SNVT  configura¬ 
tion  parameters  and  variables.  Verify  that  points  defined 
in  sequence  and  points  list  are  represented  by  SNVT 
variables  in  the  LNS  database.  Verify  that  configuration 
parameters  as  required  for  sequence  of  operation  are 
identified. 


Review  product  data  sheets  and  ensure  LonMark  certification  status 

Ensure  plug-in  application  is  provided  for  each  ASCtype  with  software  submittal,  contact  the  submitting  contractor 


Unless  otherwise  approved,  all  necessary  Configuration  Parame-  Ensure  plug-in  application  is  provided  for  each  ASC  type  with  software  submittal,  contact  the  submitting  contractor 
ters  and  network  configuration  inputs  (NCIs)  for  the  sequence  and  for  file  names  for  clarification  if  required, 
application  in  which  the  ASC  is  used  shall  be  fully  configurable 
through  an  LNS  plug-in.  This  plug-in  shall  be  submitted  as  speci¬ 
fied  for  each  type  of  ASC  (manufacturer  and  model).  (Note:  con¬ 
figuration  accomplished  via  hardware  settings  does  not  require 
configuration  via  plug-in) 

Local  Display  Panel  (LDP):  The  Local  Display  Panel  shall  be  an  Ensure  that  the  LDP  communicates  via  LonWorks  protocol.  If  the  contractor  provides  an  LDP  that  is  embedded  in  a 
Application  Specific  Controller  (ASC)  with  a  display  and  navigation  GPPC  it  shall  permit  access  to  display  and  adjustment  of  SNVTs  that  are  external  to  the  GPPC  that  the  LDP  exists  in. 
buttons.  It  shall  provide  display  and  adjustment  of  SNVT  inputs  Ensure  plug-in  and  project  application(s)  are  included  in  software  submittal, 
and  SNVT  outputs  as  shown. 


#  Priority  Category 


17  High  DDC  Hardware 


18 

Med 

DDC  Hardware 

3.2.4.a 

19 

High 

DDC  Hardware 

3.2.4.b 

20 

High 

DDC  Hardware 

3.2.4.C 

21 

High 

Scheduling 

3.4.2.2 

Scheduling 
22  High  Scheduling 


Scheduling 


Specification  Requirement 


Limited  Test: 
Submittals  Only 


Detailed  Test: 
Network  Configuration  Tool 


2.14.4. b  All  programming  software  required  to  program  the  GPPC  shall  be  Ensure  GPPC  application  and  source  code  files  are  provided  with  software  submittal.  Contact  submitting  contractor 

delivered  to  and  licensed  to  the  project  site  as  specified.  Copies  of  for  details  concerning  applications  and  source  code  files  if  the  reviewer  is  unfamiliar  with  the  vendor's  products, 
the  installed  GPPC  application  programs  as  source  code  compati¬ 
ble  with  the  supplied  programming  software  shall  be  submitted  as 
specified.  The  submitted  GPPC  application  program  shall  be  the 
complete  application  necessary  for  the  GPPC  to  function  as  in¬ 
stalled  and  be  sufficient  to  allow  replacement  of  the  installed 
controller  with  a  GPPC  of  the  same  type. 

3.2.4. a  Each  gateway  shall  communicate  with  and  perform  protocol  Review  record  drawings  and  riser  diagrams  to  ensure  third  party  networks  are  not  employed  and  gateway  communi- 

translation  for  non-CEA-709.1B  control  hardware  controlling  one  cates  with  only  one  unit  or  is  monitor  only  on  multiple  units, 
and  only  one  package  unit  or  monitor  only  on  multiple  units 

3.2.4. b  Non-CEA-709.1B  control  hardware  shall  not  be  used  for  controlling  Review  record  drawings  and  riser  diagrams  to  ensure  that  gateway  communicates  only  with  package  unit  controller, 

built-up  units.  not  third  party  external  controls 


scheduling  functions. 


Review  device  points  schedules  to  ensure  scheduling  not  performed  by  the  Gateway  device.  Ensure  output  (NVO) 
SNVT  occupancy  and  mode  are  status  points  for  equipment  on  the  proprietary  port  of  the  gateway. 


3.4.2.2  The  System  Scheduler  functionality  shall  reside  in  either  a  piece  of  Review  As-Built  Documentation  to  determine  the  location(s)  of  the  default  scheduler(s).  The  default  scheduler  may 
DDC  Hardware  dedicated  to  this  functionality  or  in  the  DDC  Hard-  reside  in  one  or  more  pieces  of  dedicated  hardware,  it  may  reside  in  certain  brands  of  ANSI/CEA-852  LON  to  IP 
ware  controlling  the  system  AHU.  A  single  piece  of  DDC  Hardware  routers,  or  in  a  GPPC  schedule  module.  Once  the  scheduler  is  identified,  if  scheduling  is  performed  in  anything  other 
may  contain  multiple  System  Schedulers.  A  unique  System  than  a  GPPC,  confirm  a  different  output  SNVT  of  SNVT_occupancy  exists  for  each  major  system  in  the  facility  by 

Scheduler  shall  be  provided  for:  each  AHU  including  it's  associated  reviewing  the  points  schedules. 

Terminal  Units,  and  each  stand-alone  Terminal  Unit  (those  not 
dependent  upon  AHU  service)!  or  group  of  stand-alone  Terminal 
Units  acting  according  to  a  common  schedule]. 


Each  System  Scheduler  shall  provide  the  following  functionality: 

Scheduled  Occupancy  Input:  Accept  network  variable  of  type 
SNVT_occupancy  (as  defined  in  the  LonMark  SNVT  List).  Input 
shall  support  the  following  possible  values:  OC_STANDBY, 
OCOCCUPIED  and  OCJJNOCCUPIED. 

Occupancy  Override  Input:  Accept  network  variable  of  type 
SNVT_occupancy  (as  defined  in  the  LonMark  SNVT  List).  Input 
shall  support  the  following  possible  values:  OC_STANDBY, 
OC_OCCUPIED,  OCJJNOCCUPIED,  and  OC_NUL. 


Review  Network  variable  list  of  the  scheduler  and  identify  an  input  SNVT_occupancy  point  for  each  system  as  de¬ 
fined  by  the  project  scope  of  work.  Identify  the  correct  range  (OCC_STANDBY,  OCC_OCCUPIED,  OCC_UNOCCUPIED) 
listed  on  points  schedule. 

Review  Network  variable  list  of  the  scheduler  and  identify  an  override  input  SNVT_occupancy  point  for  each  system 
as  defined  by  the  project  scope  of  work. 
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# 

Priority 

Category 

Para  # 

Specification  Requirement 

Limited  Test:  Detailed  Test: 

Submittals  Only  Network  Configuration  Tool 

24 

Med 

Scheduling 

3.4.2.C 

Space  Occupancy  Inputs:  For  systems  with  multiple  occupancy 
sensors,  accept  multiple  inputs  of  network  variable  type 
SNVT_Occupancy  (as  defined  in  the  LonMark  SNVT  List).  Input 
shall  support  the  following  possible  values:  OC_OCCUPIED, 
OC_UNOCCUPIED,  and  OC_NUL.  For  systems  with  a  single  occu¬ 
pancy  sensor,  accept  a  network  variable  input  of  type 
SNVT_Occupancy  or  a  hardware  binary  input  (Bl)  indicating  the 
space  occupancy  status  as  Occupied  or  Unoccupied. 

Review  Network  variable  list  of  the  system  controller  and  identify  Sensor(s)  input(s)  SNVT_occupancy  point  for  each 
occupancy  sensor  as  defined  by  the  project  scope  of  work. 
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High 

Scheduling 

3.4.2.d 

Air  Handler  Occupancy  Output:  For  a  System  Scheduler  for  a 
system  containing  an  air  handler,  output  one  or  more  SNVTs 
indicating  the  desired  occupancy  status  as  one  of  the  following 
possible  values:  Warm-Up-Cool-Down  (when  required  by  the  AHU 
Sequence  of  Operation),  Occupied  and  Unoccupied. 

Review  Scheduler  Output  Network  variable  list.  Ensure  output  SNVT_occupancy  point  exists  for  each  controlled 
system.  Ensure  Range  of  variable  includes  only  the  following  values:  OC_STANDBY,  OC_OCCUPIED,  and 
OCJJNOCCUPIED 
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High 

Scheduling 

3.4.2.d 

Terminal  Unit  Occupancy  Output:  For  a  System  Scheduler  for  a 
stand-alone  terminal  unit,  [a  group  of  stand-alone  terminal  units 
acting  according  to  a  common  schedule,]  or  a  group  of  terminal 
units  served  by  a  single  air  handler,  output  one  or  more  SNVTs 
indicating  the  desired  occupancy  status  as  one  of  the  following 
possible  values:  Occupied  and  Unoccupied. 

Review  Scheduler  Output  Network  variable  list.  Ensure  output  SNVT_occupancy  point  exists  for  each  controlled 
system.  Ensure  Range  of  variable  includes  only  the  following  values:  OCC_OCCUPIED  and  OCJJNOCCUPIED.  Note: 
The  possibility  exists  that  the  air  handler  will  pass  the  occupancy  command  to  the  terminal  units. 
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High 

Scheduling 

3.4.2.e 

Default  Schedule:  Incorporate  a  24-hour  7-day  default  schedule  as 
shown  on  the  drawings  which  may  be  activated  and  deactivated 
by  the  System  Scheduler  Logic. 

Review  Scheduler  default  schedule  parameters  in  as-built  documentation  and  verify  that  the  default  schedule  is  set 
for  24-hour  7-day  operation. 
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High 

Other/Misc 

none 

BPOC  location  and  network  drop  IP  issues 

Determine  if  the  target  building  has  DOIM  IP  network  installed  in  the  building.  If  the  IP  network  is  currently  in  the 
building  then  plans  should  show  extension  of  an  IP  drop  from  the  DOIM  IP  closet  to  the  BPOC  location.  If  the  IP 
network  does  not  exist  in  the  building  then  the  plans  should  show  the  supplying  of  the  IP  network  infrastructure  to 
the  target  building.  DOIM  will  need  to  help  plan/execute  the  installation  of  the  IP  network  into  the  target  building. 
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